Les Standards sont à la mode. Les webmasters ont redécouvert depuis quelques mois (une ou deux années au plus), des balises qui leur étaient totalement étrangères (ou plutôt qui leur paraissaient peu utiles) auparavant. C'est le cas des Listes de Définition (<dl>), ou des classiques <strong> et <em> venus "remplacer" les déclassées <b> et <i>.
Un vent nouveau de sémantique souffle dans le milieu bien pensant du webmastering : "des <div> tu n'abuseras point", "les <hn> tu utiliseras pour tes titres et non les paragraphes", "les listes tu choisiras pour tes menus", etc.
Ce qui ne dérangeait (presque) personne avant devient un sacrilège aujourd'hui.
Cette prise de conscience est tout à fait légitime. Nous savons tous que les Standards sont une brique essentielle pour l'avenir d'un Internet pour tous.
Par contre, j'ai l'occasion d'observer de plus en plus fréquemment une sorte de "sur-standardisation", de sémantisation à outrance (voir à ce sujet la "strictite aveugle" en fin de ce billet).
De plus en plus d'"experts" dans le domaine ont une interprétation des recommandations W3C qui leur est propre, confondant souvent ce que l'on peut faire et ce que l'on doit faire.
Les Standards W3C sont fréquemment clairs et stricts, mais peuvent parfois se révéler vagues ou même contradictoires (erronés ?).
Parmi ces "Règles-à-ne-pas-enfreindre-sous-peine-de-châtiment-exemplaire", j'ai retenu trois points qui paraissent des évidences mais qui mériteraient peut-être une révision de point de vue :
- XHTML 1.1 tu utiliseras
- Des Listes pour tes menus tu choisiras
- Les Tableaux tu banniras
XHTML 1.1 tu utiliseras
On lit de plus en plus fréquemment des exclamations comme "Hey, mais tu n'es même pas en XHTML 1.1, pauvre de toi ! Ne sais-tu pas (arriéré) qu'il s'agit de la norme actuelle à adopter, malheureux ?".
XHTML 1.1 est effectivement la norme actuelle officielle du langage Web, et comme le recommande le W3C lui-même, chacun est invité à employer les dernières normes en date lorsqu'elles sont disponibles.
Soit. Mais avant d'être plus royaliste que le roi, passez faire une visite sur le site du W3C pour vous assurer qu'il est bien déclaré en… XHTML 1.0 ! Ce n'est pas une critique ni un reproche, loin de là. L'explication est d'ailleurs très simple : XHTML 1.1 n'est tout simplement pas encore "adapté à son environnement", c'est à dire - entre autre - à certains navigateurs (Internet Explorer par exemple).
On peut même aller plus loin en disant que le site du W3C n'est pas en XHTML, mais en… HTML (ou un langage approchant).
D'ailleurs Alsacréations est dans le même cas... et votre site soit-disant "XHTML 1.0 ou 1.1 Valid !", n'est très certainement rien d'autre qu'une sorte de "soupe" en pseudo-HTML.
Pour généraliser, on peut dire que plus de 99% des sites actuellement déclarés en XHTML sont du HTML.
Tout simplement parce que tous nos sites sont présentés avec un type mime "text/html" (ce que vous déclarez dans le "content" de votre <head>)... ainsi qu'un type mime correspondant, envoyé par le serveur.
XHTML peut être présenté comme du HTML (type mime "text/html") ou du XML type mime "application/xhtml+xml"... problème : Internet Explorer ne reconnaît pas ce second type mime et personne (ou presque) ne l'utilise.
En clair, presque tous les sites actuels ne sont en fait interprétés que comme du HTML.
Laurent Denis en parle bien mieux que moi dans un billet très clair : http://blog-and-blues.org/weblog/2004/06/11/243-xhtml11-beaucoup-de-bruit-pour-rien
Pour élargir le débat, voici deux lectures anglophones très intéressantes sur le sujet : "Servir du XHTML en tant que text/html jugé néfaste" (Ian Hickson) [fr] et "XHTML is invalid HTML" (Ann Van Kesteren) [en].
Des Listes pour tes menus tu choisiras
La sémantique demande que l'on choisisse chaque balise en fonction de son rôle et non de son aspect par défaut.
Un menu de navigation n'est rien d'autre qu'une liste de liens et le choix sémantique est vite fait : balises de listes non ordonnées (ou ordonnées plus rarement).
Une liste permet aux navigateurs textuels ou dont les styles CSS ont été désactivés de s'afficher structurellement, les items les uns sous les autres et de manière claire.
En y réfléchissant, il n'existe pas (plus) de balise réellement adéquate pour structurer un menu de navigation : <ul> est évidemment approprié, mais ne relève que de l'extrapolation de la définition originelle d'une liste.
Pour info, selon mon dictionnaire, "liste" :
Suite continue, hiérarchisée ou non, de noms (de personnes ou d'objets) ou de signes généralement présentés en colonne.
La liste convient à un menu, mais n'est pas faite spécifiquement pour ça au départ.
En effet, qu'est-ce qui me dit objectivement qu'une liste de liens est un menu ? Bien-sûr qu'on s'en doute, mais finalement en allant faire un tour sur un site web (prenons un blog), on y trouve des Listes de liens amis, des listes d'autres blogs suivis, des listes de sponsors, etc. Tout cela sans oublier la liste qui désigne le "vrai" menu de navigation.
Toutes ces listes sont structurées à l'identique. Pourquoi celle-ci indiquerait le menu et pas une autre ? Comment permettre d'identifier clairement le menu parmi les autres listes ? Un id='menu' suffit-il ? Un title='menu' est-il plus approprié ?
Pour ce genre de raisons, l'argument de dire : "c'est une liste de liens donc c'est le menu" est un peu fragile.
Le dossier "Plongez dans l'Accessibilité" du site La Grange a choisi une solution qui me paraît relativement intéressante :
- Le menu de navigation général du site est structuré dans une liste <ul>
- Le menu horizontal ("plongez dans...") n'est qu'une suite de liens séparés par un caractère "pipe" (|)
- Le sommaire du chapitre (titre + description s'y rapportant) est structuré en liste de définition <dl>
Cette méthode permet d'isoler clairement le menu général des autres structures similaires.
Les menus horizontaux
Même s'il s'agit d'une généralisation ou d'une extrapolation, l'utilisation de listes <ul> pour construire un menu est tout à fait approprié et a un avantage indéniable : sur un navigateur texte ou lorsque les CSS ne sont pas activés, les éléments s'affichent de façon ordonnée en colonne.
Mais justement, une question concerne la présentation de menus horizontaux : pourquoi se forcer à les afficher sous forme de colonne sur les navigateurs textuels ?
Un menu horizontal conçu à l'aide de listes affichées de façon linéaire, aura un rendu vertical sur ces navigateurs, ce qui a des effets sur sa fonction : si le menu a été créé pour être horizontal, c'est pour remplir une fonction qui a été étudiée au départ.
Or, sans feuilles de styles, ce menu aura un rendu tout à fait différent du rendu sur les autres navigateurs.
Le site de La Grange n'utilise pas une liste non ordonnée pour son menu horizontal, il s'affiche de façon linéaire également sur les navigateurs textuels et ne pose aucun soucis de sémantique : il reste un groupe de liens délimités dans un bloc.
Nous en arrivons au fait : si les listes <ul> ont prouvé leur utilité en ce qui concerne les menus verticaux, sont-elles vraiment aussi performantes dans le cas de menu horizontaux ?
Le seul soucis qui me vient à l'esprit serait que des liens disposés les uns à côtés des autres seraient plus difficiles à cerner et à différencier, d'où la technique de séparation utilisée par le site de La Grange (utilisation de caractères spéciaux).
Si vous préférez ne pas afficher de caractères spéciaux de séparation, placez-les simplement dans un <span> muni d'un "visibility : hidden", ou donnez-leur la même couleur que le fond du menu.
Pour information, le site de La Grange n'est pas le seul dans son cas, le site du W3C lui-même dispose d'un menu horizontal sans liste.
Sa structure est d'ailleurs assez... originale :
<div> <map name="introLinks" id="introLinks" title="Introductory Links"> <div class="banner"> <span class="invisible"><a class="bannerLink" title="Skip introductory links and the mission statement" href="#technologies" shape="rect">Skip to Technologies</a> |</span> <a class="bannerLink" title="W3C Activities" accesskey="A" href="/Consortium/Activities" shape="rect">Activities</a> | <a class="bannerLink" title="Technical Reports and Recommendations" accesskey="T" href="/TR/" shape="rect">Technical Reports</a> | <a class="bannerLink" title="Alphabetical Site Index" accesskey="S" href="/Help/siteindex" shape="rect">Site Index</a> | <a class="bannerLink" title="Help for new visitors" accesskey="N" href="/2002/03/new-to-w3c" shape="rect">New Visitors</a> | <a class="bannerLink" title="About W3C" accesskey="B" href="/Consortium/" shape="rect">About W3C</a> | <a class="bannerLink" title="Join W3C" accesskey="J" href="/Consortium/Prospectus/Joining" shape="rect">Join W3C</a> | <a class="bannerLink" title="Contact W3C" accesskey="C" href="/Consortium/Contact" shape="rect">Contact W3C</a> </div> </map> </div>
Titres de menu
Il n'existe pas (plus) de méthode pour associer un titre explicitement à un menu. La balise <hn> définit un titre de section.
Un menu est un moyen de naviguer entre ces sections ou à l'intérieur de la section... mais en lui-même fait-il partie de la section ? Fait-il partie du contenu s'il sert à naviguer dans ce contenu ? Le sommaire d'un livre fait-il partie du contenu de ce livre ?
Il me paraît incongru d'employer le même balisage pour le titre de contenu et le titre de menu.
D'autant plus qu'en appliquant un titre <hn> à un menu, on l'applique à toute la section et non explicitement à ce menu.
Bien sûr, il reste possible d'ajouter encore une balise supplémentaire générique pour entourer tout ce beau monde, voir un billet de Laurent Denis à ce sujet.
C'est là qu'interviennent les Listes de Définition autrefois quasi inutilisées et qui à présent, portés par une mode nouvelle, reviennent en force.
En l'état actuel du XHTML 1.0, les listes de définition couvrent un manque flagrant. Leur champ d'action autorisé par le W3C est large et leur efficacité l'est également : plutôt que d'utiliser des balises génériques ou des titres de section, la structure en <dl> est très claire : "titre / élément se rapportant au titre".
L'un des exemples proposés par le W3C : Another application of DL, for example, is for marking up dialogues, with each DT naming a speaker, and each DD containing his or her words.
.
A moins d'être plus puriste que le W3C lui-même, les Listes de Définitions sont tout à fait adaptées à la conception de menus hiérarchiques avec une structure de la forme "titre / liens se rapportant au titre"
Les Tableaux tu banniras
Dernier point qui réunit les puristes des Standards du Web : le refus catégorique de l'utilisation des tableaux pour les données de présentation.
Là encore, le principe est tout à fait louable mais ce qui est à critiquer est l'excessive agressivité qui accompagne en général ce précepte : la moindre trace de cellule devient vite une verrue à cautériser d'urgence (ne le faites pas chez vous).
Effectivement, les tableaux posent des problèmes qu'il est nécessaire de prendre en compte pour permettre une Accessibilité maximale du document.
Le W3C déconseille lui-aussi l'utilisation de tableaux pour la mise en page :
Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display. To minimize these problems, authors should use style sheets to control layout rather than tables.
Le premier hic est qu'il n'existe pas de définition objective et exhaustive de ce qu'est une donnée tabulaire : les forums, livres d'or, calendrier ou blogs font-ils partie de ce qu'on peut admettre comme donnée tabulaire ?
Ce qui pose problème avec les tableaux sont leurs enchevêtrements et imbrications, les colonnes et cellules liées (colspan, rowspan) et autres éléments de mise en forme incrustés (spacer.gif, etc.). L'ensemble forme effectivement un imbroglio déstructuré et incompréhensible lorsqu'il est proposé à un visiteur non voyant.
Ce que l'on oublie de plus en plus, avec cette mode de la standardisation à outrance, c'est qu'un tableau de présentation, simple et proprement conçu, ne pose pas de problèmes d'Accessibilité aux médias non graphiques.
A force de "déconseiller", on en vient à écarter violemment certaines utilisations des tableaux que le W3C lui-même ne réprouverait pas.
Comment s'en rendre compte ? Simplement, encore une fois en refusant d'être plus royaliste que le roi : la section WAI du W3C, celle qui informe sur ses recommandations pour l'Accessibilité, est construite... avec un tableau de présentation.
Elle n'est pas la seule dans ce cas. L'association française de référence pour les handicaps visuels, Braillenet.org, est également construite à l'aide de tableaux.
Cela peut paraître bizarre à première vue, mais cela nous fait surtout relativiser quant à cette agressivité anti-tableaux...
Conclusion personnelle
Les Standards sont nécessaires, mais comme toutes les bonnes choses, le mieux est souvent l'ennemi du bien. Il est souvent préférable de ne pas trop en faire ou faire à l'aveugle, de s'accorder des petites incartades en fonction du public visé par exemple... Rappelons qu'il ne s'agit finalement que de recommentations, après tout.
Les commentaires pour ce billet sont ouverts, mais je vous invite à participer à la discussion qui s'instaure sur le forum.
Commentaires
Pour moi, la raison pour laquelle le w3c fait des menu horizontaux séparés pas des "|" est la même que celle pour laquelle il ne passent pas leur site en XHTML 1.1.
Dans un cas c'est IE qui bloque et dans l'autre, c'est les navigateurs textuels qui n'évoluent pas pour gérer les css avec un media type tty.
Donc personne ne se force à afficher sous forme de colonne les menus horizontaux, il s'agit ici d'un manque d'adaptation à son environnement non pas du XHTML 1.1 mais du CSS2.
Après tout, un navigateur graphique sans feuille de style affichera également le menu sous forme de colonne.
Quant au fait que ces séparations restent sémantique c'est discutable.
Désolé si le sujet a déjà été abordé dans le forum, je ne suis pas allé voir.
@Raphael > "chacun est invité à employer les dernières normes en date lorsqu'elles sont disponibles."
Il faut relativiser la portée de cette citation:
- le document en question étant les directives d'accessibilité WCAG1.0... et non un document prenant spécifiquement en compte la problématique HTML4.01 v. XHTML1.0 v. XHTML1.1
- ce document visait plutôt (vu son âge) AMHA le passage au HTML4.x, qui intégrait de nouveaux supports d'accessibilité dans HTML (<label>, par exemple, sauf erreur de ma part).
Pour un exemple de méthode de réflexion sur le "choix d'une DTD", voir un document conjoint WASP-W3C: webstandards.org/learn/as...
Que de bon sens dans tout ceci.
Il me semble possible de conclure de ces exemples, que HTML et XHTML sont tout simplement pauvres sur le plan de l'expression sémantique. Et lorsqu'il y a plus notions à exprimer dans la pratique que le langage n'en distingue, alors naît l'ambiguïté et le quiproquo. D'ou les discussions sans fin.
Le web n'est pas, à aujourd'hui, structurellement clair et précis sur la sémantique, il n'y a donc pas de raison de s'y échiner. La modularisation est une voie d'enrichissement, mais ce n'est pas demain que nous verrons le bout du chemin tant sont lentes les avancées et l'harmonisation des outils (navigateurs notamment).
A propos du XHTML et du mine type "application/xml+xhtml" pourrais-tu m'expliquer ca plus en details?
Le W3C employe le mot "SHOULD" ou "MAY" et n'employe jamais me mot "MUST". Je ne vois donc pas en quoi une page validée sur leur site si on utilise text/html n'est pas valide.
Tu es apparemment d'accord avec l'autre aticle, je cite:
"En effet, à la différence du XHTML1.0, le XHTML1.1 :
* Ne doit pas être servi comme étant du HTML (avec le type Mime text/html) ;
* Doit être servi comme étant du XML ( avec le type mime application/xml + xhtml). Voir XHTML Media Types (attention à la différence entre may et should qui ont chacun un sens bien précis dans les spécifications du W3C).
"
Mais là, l'auteur devrait revoir son anglais parce que may et should c'est bien different de "Ne doit pas" ou "doit".
A mons avis, ton article n'a pas vraiment de valeur mais je souhaiterai entendre ta version des faits sur ce sujet.
Le reste de l'article est pas contre bien fait. :)