Introduction -
Structure type -
De HTML à XHTML -
Conclusion
L'objectif :
Nous l’avons vu en introduction, XHTML et CSS ont leurs rôles bien définis. Longtemps nous avons utilisé HTML, surtout ses tableaux, pour mettre en page nos documents en oubliant son utilité principale : structurer logiquement les données de la page. L’objectif de l’utilisation de ce couple XHTML / CSS est donc de séparer les deux. D’un côté, structurer le document de manière logique à l’aide d’XHTML et de l’autre, réaliser la présentation de la page à l’aide de la puissance des feuilles de styles CSS (et encore, vous verrez que cette puissance est largement perfectible).
Dans quel but ? :
L’organisme dont nous avons parlé en introduction, le W3C, est chargé de publier les standards des différents langages du Web tels que XHTML, CSS et bien d’autre encore … Avoir des syntaxes standards permettent à tous les navigateurs, si tenté qu’ils les respectent, d’interpréter et d’afficher correctement et uniformément nos pages XHTML. Alors certes, tous n’est pas encore tout rose, Internet Explorer 6 fait d’ailleurs figure de très mauvais élève, ce qui à conduit Microsoft à nous proposer Windows Internet Explorer, mais alors qu’à l’époque, les éditeurs se livraient à une guéguerre impitoyable sur le marché des navigateurs en imposant leurs propres balises (balises propriétaires), aujourd’hui, le W3C est arrivé à prendre le dessus en imposant une ligne de conduite à suivre en matière de standards.
Vous l’aurez donc compris. Ecrire correctement le code source de ses pages traduit une volonté de créer des sites standards accessibles à tous et à toutes les plateformes. Car c’est bien de cela qu’il s’agit. Il existe plusieurs systèmes d’exploitation (Windows, Linux, Mac …), plus d’une centaine de navigateurs (Internet Explorer, Opera, FireFox, Mozilla, Safari, Konqueror, Lynx …) mais surtout, plusieurs types de visiteurs. Il y a ceux qui sont dits normaux, sans handicap particulier, à qui seul l’aspect visuel du site pourrait convenir. Mais il y a ceux qui sont atteint d’handicap, qu’ils soient physiques ou mentaux, pour qui les sites Web se doivent d’être accessibles.
Sémantique :
L’accessibilité est donc au cœur du problème actuel. Un site accessible passe donc par un code source correctement structurer ce qui nous amène donc à parler de sémantique. La sémantique d’un document n’est pas, comme j’ai pu déjà l’entendre, une syntaxe correctement écrite et validée par l’outil de validation du W3C, mais plutôt une utilisation logique des balises XHTML en fonction du type de contenu. D’ailleurs, cet outil de validation ne vérifie que si la syntaxe est correcte et que les balises obligatoires sont bien présentes en fonction de la DOCTYPE utilisée. Un document syntaxiquement correct mais sémantiquement incorrect sera validé par le W3C mais inaccessible aux navigateurs alternatifs.
Voici les deux exemples de sémantiques incorrectes les plus courants :
- L’utilisation des tableaux pour la mise en page et non pour un listing de données
- L’utilisation d’une balise <p> à qui l’on applique une classe CSS "titre" au lieu d’utiliser un élément <h1>
Avec une sémantique correcte, tout le monde y trouve son compte. Les visiteurs, quelque soit le navigateur qu’ils utilisent, pourrons correctement lire le contenu de notre site que ce soit en ce souciant de la présentation visuelle ou non (tel que les navigateurs en mode texte, lecteurs de braille …), mais aussi les développeurs qui faciliterons la tache des robots d’indexation.
Quid des éditeurs WYSIWYG ?
En ce qui me concerne, j’adore parler d’un codage en mode « Bloc Notes » qui consiste de partir d’une page vierge et d’y taper le code de la première balise HTML à la dernière. Cela permet de vraiment écrire ce que l’on souhaite. Les éditeurs WYSIWYG, il est vrai, permettent de générer directement les balises HTML dans le code source en fonction de ce que l’on écrit du côté de l’éditeur graphique. Cependant, il est impossible pour un logiciel au même titre que le validateur du W3C, de savoir quel contenu est censé être un titre ou un paragraphe. Ainsi, lorsque l’on regarde de plus près le code source, après être effrayé on peut constater que bon nombre de balises <div> et <p> avec un peu de CSS intégré un peu partout ont été utilisées alors qu’elles ne sont pas forcement désirées.
Personnellement, puisqu’on me le demande parfois, peut importe l’éditeur que j’utilise, Visual Studio 2005, Dreamweaver, Golive …, je m’en sers qu’en mode code source en ce qui concerne la partie XHTML des pages.
A présent, trêve de plaidoirie et passons aux choses concrètes. Voyons quels éléments utiliser pour écrire une page XHTML valide et sémantiquement correcte.
Structure type d'une page XHTML >>