Un balisage respectueux de la sémantique : toujours possible ?

Pensez-vous qu'il soit toujours possible de mettre en place un balisage respectant la sémantique sur un design pensé d'abord de façon graphique ?

Car la sémantique, c'est facile quand on pense d'abord en terme de hierarchie et de fonction de contenu pour ensuite construire le design graphique. Mais je me retrouve parfois (dans le cadre du référencement) à sécher sur certaines constructions de sites très graphiques, pleines de tables et d'AJAX pour lesquelles je ne vois pas comment recommander un balisage propre simplement parce que le site manque de structure, et qu'il est pensé comme une application plutôt qu'un document. Je suis donc obligé de faire des entorses par rapport aux standards et à la logique, à mon grand regret...

Je ne sais pas si je suis très clair, je vous donnerai bien un exemple mais je suis tenu à une certaine confidentialité...
Modifié par sebastien billard (27 Aug 2008 - 15:36)

La réponse est plutot difficile: tout dépend du design

Sur les designs simples, evidemment oui, par contre les designeurs etant parfois un peu "tordus", il est nécessaire par moments de devoir rajouter des balises non essentielles pour les besoins de la feuille de style.
Je ne pense pas que ce soit un problème en soit pour autant, tant que tu ne rajoutes pas "trop" de balises.

sebastien billard a écrit :
Pensez-vous qu'il soit toujours possible de mettre en place un balisage respectant la sémantique sur un design pensé d'abord de façon graphique ?

Car la sémantique, c'est facile quand on pense d'abord en terme de hierarchie et de fonction de contenu pour ensuite construire le design graphique. Mais je me retrouve parfois (dans le cadre du référencement) à sécher sur certaines constructions de sites très graphiques, pleines de tables et d'AJAX pour lesquelles je ne vois pas comment recommander un balisage propre simplement parce que le site manque de structure, et qu'il est pensé comme une application plutôt qu'un document. Je suis donc obligé de faire des entorses par rapport aux standards et à la logique, à mon grand regret...

Je ne sais pas si je suis très clair, je vous donnerai bien un exemple mais je suis tenu à une certaine confidentialité...

Tu as toi-même donné la réponse: faire des entorses. Tout est affaire de compromis. À l'impossible nul n'est tenu: je préfère quelques entorses avec une mise en page en tableaux que des contorsions à coups de div qui ne font, finalement, que compliquer la tâche pour la personne qui devra prendre la suite. Est-il si critique que cela qu'une liste de liens soit présentée dans des cellules de tableau adjacentes (à condition que la linéarisation se passe bien ) si le passage à une liste induit une vraie révolution du code de la page et un temps de développement explosif?

Personnellement quand je code, je m'en fiche un peu du validateur, je pense plutôt à Google et aux synthèses vocales. Un code valide peut être totalement illisible pour Google et Jaws (synthèse vocale utilisée par des non-voyants). Il y a des bases, comme utiliser les balises qui correspondent au contenu, fermer toutes les balises, mettre le maximum de détails (alt et title) etc...

Le validateur n'est pas un serial killer qui se cache derrière toi

Bonjour à tous,

a écrit :
... qu'il est pensé comme une application plutôt qu'un document.

Dans chacune de vos réponses, vous avez éclipsé le mot le plus important : "application".

Je pense que ce qui intéresse Sébastien c'est surtout de connaître la démarche à suivre / que vous suivez lors de la réalisation d'une application web complexe du style diagramme & autres joyeusetés (peut être me trompe-je ) ce qui empêche le respect "pur" des standards ...

Etant justement employé dans l'applicatif web, je dirai que les limites des technologies web poussent à cela (ou pour aller plus loin les demandes) ...
Modifié par yodaswii (28 Aug 2008 - 09:58)

Effectivement, pour une liste de liens comme celle de ton exemple le problème n'est pas bien grave.

Un de mes problèmes par exemple, c'est un titre formant une expression normallement d'un seul tenant mais qui pour des raisons graphiques est coupé en deux (div distinctes, heureusement ça linéarise bien). Comment baliser ces deux morceaux d'un même titres si je ne peux résoudre cette division ? Une même balise <hn> pour les deux morceaux ?

Je suis pas un obsédé de la validation, ce qui m'intéresse c'est un code logiquement structuré, à la fois pour le référencement et pour l'utilisateur.

Effectivement, il n'existe de mémoire pas grand'chose en HTML pour qualifier des relations entre deux éléments:
1. le duo id/for pour les formulaires
2. id/headers pour les tableaux
3. à la limite, l'attribute rel sur les liens, mais cela qualifie plutôt des relations entre documents différents : voir les valeurs reconnues pour rel (mais ce n'est pas de l'HTML "pur")

Ou bien, comme tu l'indiques, expliciter que ces éléments dépendent d'un même troisième: les faire dépendre d'un hn que tu cacherais de la consultation graphique de la page par exemple.

sebastien billard a écrit :
Comment baliser ces deux morceaux d'un même titres si je ne peux résoudre cette division ?

<h1>
	<span class="machin">Machin</span>
	<span class="truc">et puis Truc</span>
</h1>

Après ça dépend du genre de «division» dont tu parles. Dans des cas un peu extrêmes il faudra sans doute deux éléments, mais là sans avoir l'exemple exact sous le nez je serais bien incapable de seulement visualiser le problème.

Une question, Sébastien: quand tu parles de logique d'application, à quoi penses-tu? À des contenus structurés d'une manière peu parlante en lecture linéaire, et disposés comme le fond certaines applications métier par exemple, ou bien à des éléments d'application web exploitant des effets en JavaScript pour palier aux carences d'HTML 4?
J'ai un peu bossé sur ce deuxième cas de figure (intégration pour des applis web), et en général je faisais du code non accessible pour les quelques éléments de ce genre (un «cropper» en HTML+CSS+JS, par exemple). Sauf à bosser à fond sur ARIA, et encore, ce genre de machin est ingérable en termes de «sémantique», car il n'existe tout simplement pas d'éléments pour ça. J'utilise alors des éléments «neutre» (DIV, SPAN...). Côté accessibilité, c'est peut-être gérable, mais l'accessibilité des applications web (ARIA) est un sujet plus complexe que celle des contenus (WCAG), et je le connais mal. S'il n'y a pas de demande (et de budget) spécifique du client pour ça, ben je zappe complètement l'accessibilité pour les quelques éléments et fonctions qui ne «cadrent» pas dans la logique «contenus».

Je n'avais pas pensé aux span en effet.

Quand je parle d'application, je veux dire en fait que l'interface du site, utilisant des éléments mouvants (comme une application) n'a pas du tout été pensé comme un document. Je sais pas si je suis très clair.

Merci en tout cas pour toutes vos réflexions