XHTML 2 vs. HTML 5 (traduction)

Voici la traduction d'un article de Mike Malone sur les spécifications XHTML 2.0 et HTML 5.

" Remontons le temps d'une dizaine d'années pour arriver au 18 décembre 1997. Internet Explorer 4 est disponible depuis trois mois. La foundation Mozilla n'a pas encore été formée, et leur navigateur Firefox est à des années de sa mise en ligne. Il n'y a pas de XMLHttpRequest ... et pas même de XML tout court. Ce jour-là, il y a plus d'une décennie, HTML 4.0 devient une recommandation officielle du W3C.

C'est dans ce contexte que les standards actuels du web furent développés. Bien-sûr, il y a eu des améliorations depuis. XHTML 1.0 est devenu une recommandation en 2000 et CSS 2 est maintenant ( à peu près) reconnu par les principaux navigateurs. Mais les fondations mêmes du Web - ce socle commun sur lequel se construit chaque site web, des sites " brochures " aux applications complexes - sont restées pratiquement inchangées.

Ou du moins jusqu'à maintenant. Après ce qui semble être une longue pause, les choses commencent à changer au W3C - deux spécifications concurrentes sont maintenant en train d'être développées pour remplacer les standards vieillissants HTML 4.x et XHTML 1.x. Ces deux initiatives sont menées sous les auspices du W3C (bien que cela n'ait pas toujours été le cas) et les deux sont, à mon avis, bien supérieures à la moisson actuelle des langages à balises du web. Je parle ici de HTML 5 et XHTML 2.0. Et si vous êtes en train de lire ce post, vous deviendrez probablement très familier avec l'un de ces langages (ou les deux) dans les années à venir.

Un peu d'histoire

Le travail sur XHTML 2.0 a commencé peu de temps après la reconnaissance de XHTML 1.1 en tant que recommandation. Le premier projet de travail XHTML 2.0 a été mis en ligne en 2002 mais une grande partie de ce document était alors dans un état non-normatif, incomplet (et il l'est toujours). En 2004, des acteurs essentiels de l'industrie web - développeurs, concepteurs, propriétaires de contenu - mécontents de la direction que prenait le groupe de travail sur XHTML 2 et mettant en cause le process fermé du W3C, décidèrent de prendre un nouveau départ et de développer leur propre standard.

C'est ainsi qu'en 2004 une coalition indépendante appelée WHATWG (Web Hypertext Application Technology Working Group) vit le jour. Le groupe commença à travailler sur une spécification appelée Web Applications 1.0. En avril 2007, le W3C vota unanimement en faveur d'une proposition visant à adopter la spécification du groupe à titre d'examen. Les membres originels du WHATWG commencèrent à travailler au sein du W3C en tant que groupe de travail sur le HTML et continuèrent à développer leur proposition, qui fut alors renommée HTML 5. HTML 5 pourrait donc bien devenir un jour une recommandation du W3C au même titre que XHTML 2.0 (bien que ce jour soit encore bien éloigné, et que le W3C ait déjà manqué plusieurs jalons clés).

Survol de XHTML 2.0

XHTML 2.0 est exclusivement basé sur XML, suivant ainsi l'héritage de SGML et les spécificités des langages à balise actuels. XHTML 2.0 est censé être un " langage à visée généraliste ", avec un ensemble minimal de fonctionnalités par défaut, qui peuvent être facilement étendues en utilisant CSS et d'autres technologies (Xforms, XML Events, etc). C'est une approche modulaire qui permet au groupe XHTML 2 de rester centré sur un balisage de document générique, tandis que d'autres développent des mécanismes pour améliorer la présentation, l'interactivité, la construction de document, etc.

La priorité numéro un pour le groupe de travail XHTML 2 est de séparer plus encore ce qui relève du contenu et de la structure du document de ce qui relève de sa présentation. On peut citer comme autres objectifs d'améliorer l'utilisabilité, l'accessibilité, l'internationalisation, l'indépendance vis-à-vis de l'outil applicatif, l'integration avec le web sémantique et de diminuer les recours aux scripts. Le groupe s'est moins attaché au problème de rétro-compatibilité que le groupe précédent (et que le groupe de travail sur HTML), ce qui les a conduits à abandonner une partie du bagage syntactique présent dans des versions précédentes d'HTML. Le résultat est un langage plus clair, plus concis, qui corrige de nombreux points faibles du balisage web.

Survol de HTML 5

Alors que XHTML 2.0 se veut révolutionnaire, le groupe de travail sur HTML a suivi une approche plus pragmatique et a conçu HTML 5 dans une perspective d'évolution par rapport aux technologies existantes. HTML 5 constitue une sorte d'avancée incrémentale, qui reste en grande partie compatible avec les standards HTML 4/XHTML 1 actuels. Cependant, HTML 5 offre une quantité de changements et d'extensions par rapport à HTML 4/XHTML 1 qui résout de nombreux défauts présents dans les spécifications antérieures.

HTML 5 vise à écarter HTML du balisage de document et à le transformer en un véritable langage pour les applications web. Afin d'atteindre ce but, une grande partie de la spécification est axée sur la création d'un environnement de développement d'application web côté client, qui est plus robuste, et qui contient plus de fonctionnalités, et ce grâce à une offre variée d'API. La spéc stipule, entre autres, que les implémentations doivent donner les moyens de fournir un stockage persistant côté client (à la fois clé/valeur et des moteurs de stockage SQL), des APIs pour la lecture de l'audio et de la vidéo, de la conception 2D à travers l'élément canvas, du messaging cross-document, des événements envoyés par le serveur, et une API de networking.

La spécification HTML 5 maintient une syntaxe à la SGML qui est compatible avec les spécifications HTML actuelles (bien que certaines propriétés ésotériques de SGML ne soient plus longtemps maintenues). Est aussi incluse dans la spécification une seconde " Sérialisation XML " qui permet aussi aux développeurs de produire des documents XML valides. Ainsi, en maintenant une sérialisation à la SGML, le groupe de travail HTML 5 a trouvé un équilibre entre le pragmatisme et le progrès. Les développeurs peuvent choisir de baliser le contenu soit en utilisant la sérialisation HTML (qui ressemble plus à HTML 4.x) ou la sérialisation XML (qui ressemble plus à XHTML 1.x).

Caractéristiques similaires

Il ne devrait pas sembler surprenant que les deux groupes de travail proposent un certain nombre de caractéristiques similaires, visant à effacer différentes ombres noires connues des développeurs web, et qui devraient être accueillies en tant que nouveaux atouts pour la prochaine génération de langage à balise.

Suppression des éléments de présentation

Un certain nombre d'éléments ont été enlevés à la fois de XHTML 2.0 et HTML 5 car ils sont considérés comme étant exclusivement liés à la présentation. Le consensus actuel est que la présentation devrait être prise en compte par les feuilles de style.

Les documents HTML 5 et XHTML 2.0 ne peuvent plus contenir les éléments suivants : basefont, big, font, s, strike, tt, et u. XHTML 2.0 a aussi supprimé les éléments small, b, i, et hr alors que HTML 5 les redéfinit en leur donnant un sens non-présentationnel. Dans XHTML 2.0, l'élément hr a été remplacé par separator par soucis d'éviter toute confusion (puique l'élément hr, qui signifie horizontal rule (barre horizontale) n'est pas forcément représenté de manière horizontale ou par une barre)

Listes de navigation

Les listes de navigation ont été introduites à la fois dans XHTML 2.0 et HTML 5. Dans XHTML 2.0, la navigation est marquée en utilisant le nouvel élément nl. Les listes de navigation doivent commencer par un élément enfant label qui définit le titre de la liste. Suite à ce titre, un ou plusieurs éléments li peuvent ensuite être utilisés pour créer des balises de liens. Ce qui est aussi nouveau dans XHTML 2.0, c'est la possibilité de créer des hyperliens à partir de n'importe quel élément en utilisant l'attribut href. En combinant ces deux caractéristiques, on obtient un balisage pour la navigation à la fois simple et léger :

<nl>

<label>Category</label>

<li href= "/ " mce_href= "/ ">All</li>

<li href= "/news " mce_href= "/news ">News</li>

<li href= "/videos " mce_href= "/videos ">Videos</li>

<li href= "/images " mce_href= "/images ">Images</li>

</nl>

Dans HTML 5, c'est le nouvel élément nav qui a été introduit. Malheureusement, nav n'est pas une élément de liste, donc il ne peut pas contenir d'élément enfant li pour organiser les liens de manière logique (peut-être qu'un nouvel idiome sera développé plus tard). Et puisque les balises d'ancres sont toujours requises pour créer des hyperliens en HTML 5, le balisage pour la navigation n'est pas aussi élégant :

<nav>

<h1>Category</h1>

<ul>

<li><a href= "/ " mce_href= "/ ">All</a></li>

<li><a href= "/news " mce_href= "/news ">News</a></li>

<li><a href= "/videos " mce_href= "/videos ">Videos</a></li>

<li><a href= "/images " mce_href= "/images ">Images</a></li>

</ul>

</nav>

Formulaires avancés

Les deux spécifications ont de nouvelles caractéristiques pour créer des formulaires plus robustes et cohérents, nécessitant d'utilisant moins de scripts. Dans XHTML 2.0, les formulaires HTML standards sont complètement abandonnés au profit du standard Xforms, plus exhaustif. Le groupe de travail XHTML 2 ne contrôle pas ce standard mais il y fait référence dans sa spécification. Pour faciliter la réutilisation, Xforms sépare les données collectées du balisage pour les contrôles. C'est un langage robuste et puissant, mais qui nécessite une description qui va bien au-delà de ce post. Il suffit pour le moment de dire qu'il y aura une courbe d'apprentissage pour les développeurs qui essaieront de se mettre à niveau avec cette technologie.

HTML 5 garde les formulaires à la façon du HTML actuel mais il ajoute plusieurs nouveaux types de données qui simplifient le développement et améliore l'utilisabilité. Avec HTML 5, plusieurs nouveaux types d'éléments input ont été créées pour les adresses mail, les URLs, les dates et les heures, et les données numériques. Cela va permettre aux agents utilisateurs de fournir des composants plus sophistiqués (par exemple, des calendriers pour sélectionner une date), de mieux communiquer avec d'autres applications (comme extraire des adresses à partir d'Outlook ou d'Address Book) et de valider l'input utilisateur avant de poster les données vers le serveur (permettant ainsi de diminuer les scripts de validation côté client).

Balisage sémantique

Les deux groupes de travail ont adopté le web sémantique en permettant aux développeurs d'enrichir les métadonnées des documents. Comme il l'a fait pour les formulaires, le groupe de travail sur XHTML 2.0 a adopté une technologie plus sophistiquée, tandis que le groupe de travail sur HTML a cherché à rester simple.

Avec XHTML 2.0, les métadonnées sont insérées en utilisant plusieurs nouveaux attributs globaux issus du Metainformation Attributes Module. Le nouvel attribut global rôle, notamment, vise à décrire le sens d'un élément donné dans le contexte d'un document. Le terme technique est Embedding Structured Data in Web Pages (Insertion de données structurées au sein de page web). A nouveau, le groupe utilise un standard existant en faisant référence à RDF. Cette technologie est extrêmement puissante, mais elle est aussi compliquée.

Le groupe de travail HTML a suivi une approche plus proche de celle des microformats en surchargeant l'attribut classe avec un ensemble prédéfini de classes réservées pour représenter différents types de données. La spécification en cours liste sept classe réservées : copyright, error, example, issue, note, search and warning. Bien que surcharger ainsi l'attribut class puisse sembler porter à confusion, il est peu probable que les agents utilisateurs proposent un rendu différent pour les éléments de ces classes. Et les noms de classe sont assez spécifiques pour éviter de se faire tout soucis : si un élément a un attribut class qui a pour valeur copyright, c'est probablement un élément copyright, que le développeur soit au courant du fait qu'il s'agisse d'un attribut réservé ou pas.

Seulement avec HTML 5

Il y a plusieurs nouvelles caractéristiques que la spécification HTML 5 décrit et qui n'ont pas leur équivalent avec XHTML 2.0.

les APIs d'application web

HTML 5 introduit plusieurs APIs qui vont considérablement améliorer l'environnement de développement web côté client. Ces APIs sont ce qui place HTML 5 à part et font de cette spécification une proposition de brique technologique pour la construction d'applications web, plutôt qu'un langage à balises pour les documents. Il faut ici mentionner le fait que les détails de ces APIs sont examinés par le groupe de travail sur les APIs Web, et qu'elles seront adoptées avec ou sans HTML 5. Les nouvelles APIs et les éléments correspondants sont :

• une API pour la conception 2D utilisant l'élément canvas

• une API de lecture pour l'audio et la vidéo, permettant de supporter des formats multiples et qui peuvent être utilisés avec les nouveaux éléments vidéos et audios.

• Un stockage persistant côté client avec un support clé/valeur et des bases de données SQL.

• Une API pour les applications web offline (similaires à Google Gears)

• Une API qui permet aux applications web de s'enregistrer pour certains protocoles ou types MIMES.

• Une API pour l'édition qui peut être utilisée en combinaison avec l'attribut global contenteditable.

• Une API pour le drag and drop qui peut être utilisée avec l'attribut draggable

• Une API network permettant aux applications web de communiquer via TCP.

• Une API qui permet d'accéder à l'historique du navigateur, afin de permettre aux applications d'ajouter des événements pour que l'usage du bouton retour reste cohérent.

• Une API pour le messaging cross-document.

• Des événements envoyés côté serveur en combinaison avec le nouvel élément event-source

Nouveaux éléments

Plusieurs nouveaux éléments ont été créés dans HTML 5 et ne sont pas disponibles avec XHTML 2.0 :

• figure représente une image ou un graphique avec une légende. L'élément imbriqué legend représente une légende, tandis que l'élément img est utilisé pour l'image.

• m représente du texte balisé : cet élément peut par exemple être utilisé pour baliser des termes recherchés dans des documents résultats.

• time représente des dates et des heures

• meter représente une mesure

• datagrid représente une liste arborescente interactive ou des données tabulaires

• command représente une commande que l'utilisateur peut invoquer

• event-source est utilisé pour récupérer des événements envoyés par le serveur

• output représente un type d'output tel que celui obtenu après un calcul effectué au travers d'un script.

• progress représente le niveau de complétion d'une tâche, tel qu'un téléchargement ou lorsqu'une série d'opérations lourdes est en cours.

En plus de cela, plusieurs nouveaux éléments vont aider à baliser sémantiquement les parties d'un document. Il sont assez auto-explicatifs : section, article, header, footer, et aside. Et un nouvel élément dialog vise à représenter des conversations utilisant les éléments enfant dt pour le nom de l'interlocuteur et des éléments dd pour le texte.

Tracer les utilisateurs : pinging URIs

Le nouvel attribut ping peut être utilisé avec les éléments a et area pour tracer les utilisateurs. Plutôt que d'utiliser la redirection ou de s'appuyer sur du javascript, l'attribut ping permet de spécifier une liste d'URIs séparées par un espace qui devrait être utilisée pour faire un ping lorsque l'hyperlien est suivi.

Seulement avec XHTML 2.0

Les caractéristiques suivantes, propres à XHTML 2.0 exclusivement, méritent aussi d'être soulignées.

Tout élément peut être un hyperlien

Avec XHTML 2.0, tout élément peut être transformé en hyperlien : l'attribut href peut être utilisé avec n'importe quel élément. L'élément a devient donc obsolète, mais il est tout de fois maintenu.

Tout élément peut être une image (ou une autre ressource)

Avec XHTML 2.0, l'élément img a été supprimé. Pas d'inquiètude, cependant - n'importe quel élément peut maintenant être une image. L'idée est que toutes les images peuvent être associées à une longue description qui équivaut à l'image en elle-même. En plaçant l'attribut src à n'importe quel élément, on dit en fait à l'agent utilisateur de charger la ressource en question lorsqu'il rencontre cet élément. Si, pour n'importe quelle raison que ce soit, la ressource n'est pas disponible, la description de l'élément est utilisée à la place. Cela permet aux développeurs de fournir des ressources multiples et équivalentes en utilisant différents formats de fichiers et différentes représentations et en imbriquant des éléments les uns avec les autres.

Les lignes remplacent les sauts de ligne

Le vénérable élément br, utilisé pour insérer des sauts de ligne, a été supprimé de la spécification XHTML 2.0. Le nouvel élément l a été créé pour le remplacer. l représente une ligne de texte, et se comporte comme un span suivi d'un br si l'on compare avec les balises actuelles.

Nouveaux éléments pour le rubriquage

Les nouveaux éléments h et section ont été créés pour remplacer les éléments numérotés de h1 à h6. L'objectif est de représenter de manière appropriée la structure hiérarchique d'un document. Les balises de rubrique actuelles sont linéaires, non-imbriquées. En imbriquant des éléments section et h au sein d'éléments parent section, la structure du document est alors rendue explicite.

Nouveaux éléments

Le groupe de travail XHTML 2.0 a cherché à créer un langage plus générique, simplifié. Afin d'atteindre cet objectif, les membres de ce groupe ont essayé de ne pas ajouter de nombreux éléments spécifiques pour représenter différents types de contenu. Ils font valoir que le nouvel attribut role fournit un mécanisme permettant d'inclure des métadonnées riches, rendant ainsi des éléments spécialisés inutiles. Ceci dit, quelques nouveaux éléments ont été inclus :

• blockcode représente du code informatique

• di représente un groupe de termes reliés et des définitions au sein d'un élément dl (definition list)

• handler représente un gestionnaire d'événement, avec un attribut type spécifiant le langage du gestionnaire. Si l'agent utilisateur ne comprend pas le langage, les éléments enfants du gestionnaire sont traités (sinon ils sont ignorés). Les gestionnaires peuvent être imbriqués pour fournir de multiples implémentations dans différents langages.

Conclusion

Les deux propositions semblent prometteuses, avec de nombreuses nouvelles caractéristiques qui permettent de répondre à des problèmes actuels de développement. Mais aucune des spécifications n'est encore une recommandation officielle, et il est probable que cela reste tel quel pour un certain temps.

Malgré une formation tardive, le groupe de travail HTML 5 semble avoir reçu un support plus important de la part du monde industriel, et il est plus avancé dans le processus menant à la recommandation. Leur but est d'avoir une spéc complète, avec des implémentations multiples interopérables, d'ici la fin 2010 (mais comme je l'ai déjà dit, le W3C a déjà manqué quelques jalons dans le processus d'approbation). Avec le support de la plupart des constructeur de navigateur (la seule exception notable étant Microsoft), il est probable que cette spécification soit rapidement mise en application une fois un état stable atteint.

Ce que chacun cherche à éviter, c'est une autre guerre des standards. Heureusement, puisque les deux langages supportent les espaces de nom XML (ou, comme c'est le cas pour la sérialisation HTML de HTML 5, un switching de DOCTYPE), il est peu probable que l'on voit les mêmes genres de comportement dépendants du navigateur tels que de dans les années 1990. Les guerres des standards mises de côté, le future semble brilliant pour le développement web. Ces nouvelles possibilités de balisage et d'APIs vont fournir un environnement riche pour le développement web qui devrait réduire l'écart entre le web et les applications de type bureautique. "

---------------------------

A lire aussi : l'article sur xhtml.com qui compare les caractéristiques et les potentialités de ces deux langages