X/HTML 5 Versus XHTML 2

Contexte
Bien que les spécifications HTML 4 et XHTML 1 nous ont bien servis jusqu'à present, elles ont toutes les deux certaines faiblesses. Il faut donc soit les reviser soit les remplacer, si l'on veut satisfaire à la demande d'applications Web enrichies, générer des résultats de recherche plus pertinents, et bâtir un Web accessible à tous et via tous les moyens d'accès.
Il y a présentement deux spécifications qui se battent pour succéder au HTML 4 et au XHTML 1: le XHTML 2.0 et Web Applications 1.0 (mieux connu sous le nom deX/HTML 5). Les deux spécifications proposent deux approches différentes qui auront un impact différent sur le développement des langages de balisage.
Le XHTML 2 représente un grand bond en avant dont l'objectif est de créer une architecture qui assumera le rôle de langage hôte pour beaucoup d'autres technologies W3C existantes ou en cours de développement. Le XHTML 2 est basé exclusivement sur le langage XML, considérée par la plupart des gens comme la technologie qui permettra au Web d'atteindre son plein épanouissement.
Le développement du XHTML 2 est poussé par le principe qu'il y a une façon correcte d'utiliser un langage de balisage, et non par la façon dont le langage est actuellement utilisé.
Le X/HTML 5 est une extension des langages HTML 4 et XHTML 1 et représente un pas en avant incrémental, plutôt qu'un grand bond en avant dans le style du XHTML2.
Le fait de travailler dans les confins du HTML 4 et du XHTML 1 a poussé le X/HTML 5 à concevoir des solutions adroites pour adresser certains des défauts retrouvés dans le HTML 4 et le XHTML 1. Le X/HTML 5 peut aussi être servi comme du HTML ou du XML. Ainsi, à la différence du XHTML 2, le X/HTML 5 est influencé par les technologies courantes (technologies de navigateurs Web, etc.) et la façon dont un langage de balisage est actuellement utilisé.
Le X/HTML 5 et le XHTML 2 ont tous les deux le statut de "W3C Working Draft". On s'attend à ce que les deux spécifications changent, et il est fort probable que plusieurs années passeront avant qu'elles ne deviennent des recommandations. Cet article présente des observations sur les versions "Working Draft" en février 2007.

XHTML 2

Aspects cool du XHTML 2

Listes de navigation
Les listes de navigation sont conçues pour créer des menus de navigation. On définit une liste de navigation en utilisant l'élément nl. Une liste doit contenir un élémentlabel qui contient le titre de la liste. Par exemple:
  1. <nl>
  2. <label>You are here:</label>
  3. <li href="/">Home</li>
  4. <li href="/products/">Products</li>
  5. <li href="/products/widget/">Widgit</li>
  6. <li>Features</li>
  7. </nl>
Les listes de navigation sont cool!
Perfectionnement des listes de définitions
Les listes de définitions (l'élément dl) définissent un terme (l'élément dt) ainsi que sa définition (l'élément dd). Un seul terme peut avoir plusieurs définitions, et plusieurs termes peuvent partager la même définition. Le XHTML 2 permet de grouper des termes et des définitions, en utilisant l'élément di. Ceci rend plus clair le rapport entre un terme et sa (ou ses) définition(s), et genère un code plus facile à lire. Par exemple
  1. <dl>
  2. <di>
  3. <dt>center</dt>
  4. <dt>centre</dt>
  5. <dd>a building dedicated to a particular activity</dd>
  6. <dd>a point equidistant from its ends</dt>
  7. </di>
  8. <di>
  9. <dt>key</dt>
  10. <dd>metal device used to open a lock</dd>
  11. <dd>pitch of the voice</dd>
  12. </di>
  13. </dl>
Le perfectionnement des listes de définitions est cool!
On peut ajouter à tout élément un attribut href qui transformera l'élément en hyperlien. Par exemple:
  1. <q href="http://en.wikipedia.org/wiki/Neil_Armstrong">That's one small step for man, one giant leap for mankind</q>
Ça, c'est très cool!
acronym n'est plus
Beaucoup de contributeurs de contenu ne savent pas utiliser l'élément acronym. Le XHTML 2 permet l'usage de abbr pour représenter tous types d'abréviations, y compris les acronymes.
Cool!
bismallbigttfont et basefont ne sont plus
Le XHTML 2 dit adieu à tous ces éléments, qui sont utilisés strictement pour la mise en forme. L'élément font en particulier a souvent été utilisé de façon incorrecte, ce qui a eu l'effet de décourager les créateurs de contenu (les auteurs) d'employer les balises appropriées.
Au delà de cool!
iframe n'est plus
L'élément iframe, qui depuis toujours a posé des problèmes pour des utilisateurs des technologies au service des handicapés ne sera pas regretté.
Cool!
Une nouveau construct pour les titres
Les titres sont les constructs les plus importants lorsqu'il s'agit de s'assurer de l'accessibilité d'une page Web. Cependant, et presque sans exception, les titres numérotes h1 à h6 sont utilisés de façon incorrecte dû a la difficulté de les visualiser, et sont presque impossibles a créer dans les éditeurs WYSIWYG. Physiquement, les titres numérotés sont des constructs linéaires (éléments enfants ayant le même parent) qui sont employées pour organiser des données dans une hiérarchie logique. Ainsi, dans l'exemple suivant, vous devez faire un effort pour visualiser la structure hiérarchique du contenu.
  1. <h1>...</h1>
  2. <p>...</p>
  3. <h2>...</h2>
  4. <p>...</p>
  5. <h2>...</h2>
  6. <p>...</p>
  7. <h3>...</h3>
  8. <p>...</p>
  9. <h4>...</h4>
  10. <p>...</p>
  11. <h3>...</h3>
  12. <p>...</p>
  13. <h2>...</h2>
  14. <p>...</p>
Par contre, le nouveau construct pour les titres, qui emploie l'élément h ainsi que l'élément de regroupement section, rend la structure hiérarchique infiniment plus facile à visualiser.
  1. <h>...</h>
  2. <p>...</p>
  3. <section>
  4. <h>...</h>
  5. <p>...</p>
  6. <h>...</h>
  7. <p>...</p>
  8. <section>
  9. <h>...</h>
  10. <p>...</p>
  11. <section>
  12. <h>...</h>
  13. <p>...</p>
  14. </section>
  15. <h>...</h>
  16. <p>...</p>
  17. </section>
  18. <h>...</h>
  19. <p>...</p>
  20. </section>
L'élément h est très cool!
Perfectionnement de la composition d'extraits de code
L'élément blockcode peut être employé à la place des éléments pre et code dans la composition d'extraits de code.
  1. <blockcode>
  2. function get_random_name() {
  3. $rand_name = "";
  4. for ($i = 1; $i &lt;= 8; $i++) {
  5. $rand_name .= chr(rand(97, 122));
  6. }
  7. return $rand_name;
  8. }
  9. </blockcode>
Ca, c'est très cool!
hr est remplacé par separator
Le nom de l'élément hr, "horizontal rule", a depuis toujours posé des problèmes pour les auteurs ainsi que pour les vendeurs d'outils d'édition, puisque son nom suggère la création d'un trait horizontal, pendant que la véritable fonction de l'élément hr est de séparer une partie d'un document d'une autre. L'usage de separatorévitera une telle confusion.
C'est cool!
del et ins sont replacés par l'attribut edit
Relativement aux éléments del et ins, l'attribut edit est une façon tout à fait supérieure de signaler où le contenu a été changé. On peut l'utiliser de la façon suivante:
  1. <p>This is <span edit="deleted">cool</span><span edit="inserted">way cool</span>!</p>
La possibilité d'ajouter plus d'informations sémantiques aux éléments existants
On utilise l'attribut role pour ajouter aux éléments existants plus de sémantique et de métadonnées, ce qui permet aux moteurs de recherche et aux technologies au service des handicapés de mieux parcourir les pages Web. Dans l'exemple qui suit, on emploie l'attribut role pour indiquer que le contenu de la liste de navigation doit être utilisé comme fil d'Ariane.
  1. <nl role="breadcrumbs">
  2. <label>You are here:</label>
  3. <li href="/">Home</li>
  4. <li href="/products/">Products</li>
  5. <li href="/products/widget/">Widgit</li>
  6. <li>Features</li>
  7. </nl>
Le terme technique pour l'usage de l'attribut role est l'incorporation (embedding) du RDF dans le XHTML. Cette fonction rend le XHTML 2 très extensible et pourrait jouer un rôle primordial en aidant le Web à atteindre son plein épanouissement.
L'attribut role est super cool!

Aspects du XHTML 2 qui sont pas cool

L'élément a a été retenu
Puisqu'il est permis d'utiliser l'attribut href pour tout élément, l'élément a n'est plus vraiment nécessaire. Retenir l'élément a ne réussira qu'à semer la confusion parmi les auteurs. Par exemple, dans le HTML 4 et le XHTML 1, on peut employer l'attribut id pour transformer en ancre n'importe quel élément. Par exemple:
  1. <h2 id="introduction">Introduction</h2>
Pourtant, la plupart des auteurs préfèrent utiliser l'élément a pour créer une ancre. Par exemple:
  1. <h2><a name="introduction">Introduction</a></h2>
Retenir l'élément a est pas cool!
L'élément img a été retenu
Dans le XHTML 2, l'élément object peut accomplir tout ce que peut accomplir l'élément img. Selon la spécification, l'élément img a été retenu pour faciliter la transition vers le XHTML 2, mais en réalité, la rétention de l'élément img va finir par semer la confusion parmi les auteurs. Il faut également ajouter que l'élément retenuimg ne sera plus un élément vide, mais va pouvoir contenir un contenu de remplacement. Par exemple:
  1. <img src="W3C.png">W3C</img>
Lorsqu'un élément dans le XHTML 2 porte le même nom qu'un élément dans le HTML 4 ou le XHTML 1, mais se comporte d'une façon différente, il est fort probable que ceci portera à confusion et provoquera le débat.
Retenir l'élément img est pas cool!
Les titres numérotés sont supportés
Puisque l'élément h est la façon préférée de créer des titres, les titres numérotes ne sont plus nécessaires. Supporter à la fois l'élément h ainsi que les titres numérotes ne peut que porter à confusion parmi les auteurs.
Supporter les titres numérotes c'est vraiment pas cool!
Le développement à huis clos de la spécification XHTML 2
Le grand public sait très peu concernant le groupe XHTML 2 qui est en cours de développer ce qui pourrait devenir le nouveau langage Web. Après tout, les gars, ce n'est pas Skunk works! Vous ne travaillez pas sur une arme secrète. Laisser pénétrer la lumière!

XHTML 5

Aspects cool du X/HTML 5

Le principe des éléments de section
Le X/HTML 5 propose de nouveaux éléments qui sont capables de diviser en sections une page Web. La division en sections des pages Web facilitera le traitement du contenu par les moteurs de recherche et les technologies au service des handicapés. L'usage de ces nouveaux éléments pourrait générer un code plus facile à lire.
Le principe de diviser en sections le contenu est cool, mais les techniques d'implémentation proposées ne le sont pas.
L'élément dialog
L'élément dialog signale une conversation. Il contient des éléments dt que l'on utilise pour identifier un locuteur, ainsi que des éléments dd qui contiennent les paroles du locuteur. Par exemple:
  1. <dialog>
  2. <dt>Costello</dt>
  3. <dd>Look, you gotta first baseman?</dd>
  4. <dt>Abbott</dt>
  5. <dd>Certainly.</dd>
  6. <dt>Costello</dt>
  7. <dd>Who's playing first?</dd>
  8. <dt>Abbott</dt>
  9. <dd>That's right.</dd>
  10. <dt>Costello</dt>
  11. <dd>When you pay off the first baseman every month, who gets the money?</dd>
  12. <dt>Abbott</dt>
  13. <dd>Every dollar of it.</dd>
  14. </dialog>
C'est cool!
L'élément figure
Dans l'imprimé (manuels scolaires, journaux, magazines, etc.), les objets médias (photos, illustrations, graphiques, etc.) sont habituellement accompagnés de captions. Jusqu'à présent, les langages de balisage manquaient le construct nécessaire pour générer des captions. L'élément figure avec son élément enfant legend peuvent générer les captions d'images. Par exemple:
  1. <figure>
  2. <legend>Credit: Media Inc., 2007</legend>
  3. <img src="smith.jpg" alt="Photo: J. Smith" />
  4. </figure>
Ça, c'est très cool!
L'élément m
L'élément m représente du texte marqué ou mis en surbrillance. Cette fonction s'avère très utile lors d'une recherche par mot-cle dans une page Web générée dynamiquement, puisque l'élément m permet de mettre en surbrillance des mots-cles qui y sont retrouvés. Par exemple, suite à une recherche pour le mot-cle "snow", on pourrait modifier la page Web de la façon suivante:
  1. <p>A <m>snow</m>man is a man-like sculpture constructed out of <m>snow</m>.</p>
C'est cool!
Perfectionnement de l'élément input
L'élément input a été perfectionné pour supporter les types de données courrier électronique, URL, date, heure, et numéro. Ceci permet plus de validation côté client.
C'est cool!
Un processus ouvert
Le processus de développement du X/HTML 5 a été beaucoup plus ouvert que celui du XHTML 2. On invite tout le monde à participer a la liste de diffusion.
Les processus ouverts sont cool!

Aspects du XHTML 5 qui sont pas cool

Techniques d'implémentation des éléments de section
Le principe de diviser en sections une page Web est superbe, mais les techniques d'implémentation proposées pour le X/HTML 5 sont encombrantes, et des efforts visant à les éclaircir peuvent porter à confusion. Par exemple:
L'élément aside représente une section de page qui contient du contenu qui a un rapport tangentiel avec le contenu qui entour l'élément aside, et qui serait considéré comme étant distincte de ce contenu. Dans l'imprime, de telles sections sont souvent encadrées.
Un élément div avec un attribut role serait plus extensible et plus facile a implémenter.
On propose également l'élément nav, que l'on utilise pour identifier une section de page qui contient des hyperliens qui pointent vers d'autres pages. A-t-on vraiment besoin de l'élément nav? Le construct nl retrouvé dans le XHTML 2 donne un résultat supérieur.
De telles techniques d'implémentation sont pas cool et devraient être améliorées.
Le X/HTML 5 perpétue des faiblesses du HTML 4 et du XTHML 1
Puisque la spécification XHTML 5 assure la rétro-compatibilité, elle doit inévitablement perpétuer beaucoup de faiblesses retrouvées dans le HTML 4 et le XHTML 1. Ce ne sont pas les spécifications qui devraient chercher à être rétro-compatibles, mais plutôt les agents-utilisateurs, en supportant plusieurs spécifications à la fois.
Perpétuer les faiblesses du HTML 4 et du XHTML 1, telles les titres numérotes, et les éléments ibsmalliframe et font, est vraiment pas cool!
Le X/HTML 5 n'est pas en conformité avec la charte X/HTML 5
Le X/HTML 5 vise la rétrocompatibilité avec le HTML 4 et le XHTML 1. Pourtant, certains éléments, tels bigacronymu et tt ne figurent pas dans la spécification, pendant que la sémantique d'autres éléments, tels i et small, a été redéfinie. Par exemple, selon le spécification HTML 4.01:
i: rend le texte en italique
small: signifie "petite" police de caractères
Dans la spécification XHTML 5, les éléments i et small ont de nouvelles significations:
L'élément i sert à identifier du texte que l'on peut prononcer d'une voix ou d'un ton différent, ou du texte qui est de quelque façon que ce soit distinct du texte ordinaire, tels une désignation taxonomique, un terme technique, une expression idiomatique tirée d'une autre langue, une pensée, le nom d'un navire, ou du texte dont la présentation typographique est composée de lettres italiques.
L'élément small sert à identifier du texte en petits caractères (la partie d'un document qui contient un avertissement légal, tel le droit d'auteur) ou autres commentaires périphériques.
En redéfinissant les éléments i et small de cette façon, la rétrocompatibilité avec le HTML 4 et le XHTML 1 n'est plus assurée, puisqu'un agent utilisateur HTML 5 doit surtout interpréter un document HTML 4 d'une manière identique à celle d'un agent utilisateur HTML 4. Pour assurer la rétrocompatibilité, un construct qui était sans signification dans le HTML 4 devrait donc être sans signification dans le HTML 5.
Ne pas conformer aux objectifs de son propre charte, c'est pas cool!
Quoi, l'élément font a été retenu?
Oui, l'élément font a été retenu dans le X/HTML 5 lorsqu'il s'agit du contenu qui a été généré par un éditeur WYSIWYG. Comment justifier une telle décision? Pourquoi les éditeurs WYSIWYG sont-ils pardonnés?
Ça, c'est pas cool du tout!
La signature WYSIWYG
Tout document généré par un éditeur WYSIWYG doit inclure dans l'élément head la signature WYSIWYG suivante:
  1. <meta name="generator" content="(WYSIWYG editor)" />
ou:
  1. <meta name="generator" content="Sample Editor 1.0 (WYSIWYG editor)" />
Comment expliquer cette règle? S'agit-il d'une marque de honte? Est-ce que le rôle de la signature WYSIWYG est de signaler aux agents-utilisateurs que le code qui suit sera de piètre qualité, puisqu'il a été généré par un éditeur WYSIWYG? Et si seule une portion du document a été générée par un éditeur WYSIWYG?
Ça, c'est incompréhensible et pas cool du tout!
Les noms prédéfinis de classe sont supportés
Les noms prédéfinis sont des noms de classe CSS qui sont réservés et qui peuvent avoir une signification sémantique pour les agents-utilisateurs X/HTML 5. Le nom de classe "copyright" est le nom prédéfini dans l'exemple qui suit:
  1. <p class="copyright>...</p>
Les noms prédéfinis comprennent: "error", "example", "issue", "note", "search" et "warning". Pour compliquer les choses, on peut utiliser certains noms prédéfinis avec certains éléments, mais pas avec d'autres. Par exemple, le nom de classe "copyright" ne peut être utilisé qu'avec p et span. Le nom de classe "error" ne peut être utilisé qu'avec psectionspan et strong.
Un problème particulier posé par les noms prédéfinis de classe est évident dans l'exemple qui suit, où ceci ne signifie rien:
  1. <p class="important">
...tandis que le suivant est supposé signifier quelque chose:
  1. <p class="copyright">
Aussi, lorsque l'attribut classe est surchargé, il devient difficile d'interpréter la signification du construct. Par exemple, que veut dire le suivant:
  1. <p class="important copyright issue">
Les noms prédéfinis de classe limitent également le libre usage des noms de classe par les auteurs. Et on se demande qu'est-ce qui se produirait dans le cas où un auteur se sert aujourd'hui d'un nom de classe non prédéfini qui, a une date ultérieure, devient un nom de classe prédéfini? Est-ce que le contenu déjà généré par l'auteur assumera une nouvelle signification?
Puisque l'attribut role dans le XHTML 2 représente une solution fort supérieure, supporter les noms prédéfinis de classe dans le HTML 5 n'est pas cool du tout!
Le HTML 5 versus le XHTML 5
Même s'il vise a résoudre une fois pour toutes le débat HTML versus XHTML, la spécification XHTML 5 finit par rendre le débat encore plus complexe. La spécificationXHTML 5 dit explicitement: "de façon générale, les auteurs Web sont découragés d'utiliser le XML" au moment même où le W3C annonce le XML comme le futur du Web. C'est super embrouillant et vraiment pas cool!
Un processus trop précipité
Le X/HTML 5 est une réaction provoquée par le peu de progrès fait par le W3C dans sa recherche d'un successeur au HTML 4 et au XHTML 1. Par conséquent, le processus de développement du XHTML 5 semble précipité, la spécification elle même donne l'impression d'être tombée du ciel, et semble être le produit d'un programme de développement accéléré. Même des parties prenantes estiment que l'horaire ainsi que les étapes jalons prévus pour le développement de la spécification sont tout à fait irréalistes.

La compétition pour devenir le nouveau langage de balisage

Le X/HTML 5 et le XHTML 2 se font concurrence pour remplacer le HTML 4 et le XHML 1. Même à ce stage avancé, certains vendeurs de navigateur Web ont signalé leur préférence pour l'une ou l'autre spécification. En raison de la rapidité des discussions, tenues à huis clos, ce débat commence à polariser la communauté des défenseurs des normes Web. Au fur et à mesure que progressent les deux spécifications, des parties prenantes investiront plus d'argent dans le développement et la mise en vente de leur spécification préférée, et tous les ingrédients seront réunis pour provoquer une guerre des normes.
Puisque le Web appartient à nous tous, nous sommes tous parties prenantes à ce processus, et seul un débat honnête et ouvert peut assurer que la spécification supérieure sortira gagnante.

Notes

Pour faciliter la lecture, "HTML 4.x/XHTML 1.x" est modifié comme suit: "le HTML 4 et le XHTML 1".
Celle-ci est la traduction française de la version anglaise originale.

Lecture supplémentaire