Accueil
 chercher             Plan du site             Info (English version) 
L'histoire de XML s'écrit en ce moment même. XMLfr vous aide à la suivre et à en dégager les tendances.Les listes de discussions XMLfr sont à votre disposition pour réagir sur nos articles ou simplement poser une question.Si vous ètes passionnée(e) par XML, pourquoi ne pas en faire votre métier ?XMLfr n'est heureusement pas le seul site où l'on parle de XML. Découvrez les autres grâce à XMLfr et à l'ODP.Les partenaires grâce auxquels XMLfr peut se développer.Pour tout savoir sur XMLfr.XMLfr sans fil, c'est possible !Pour ceux qui veulent vraiment en savoir plus sur XML.L'index du site.
 Manifestations XML francophones et internationales.L'actualité des affaires et stratégies XML.L'actualité des technologies XML.Les nouveautés et l'actualités de notre site.Pointeurs sur l'actualité XML sur d'autres sites, en français comme en anglais.


HTML 5 : les documents deviennent des applications

Répondez à cet article.

La publication par le W3C de la première version de travail de la spécification HTML 5 marque la reprise de travaux interrompus depuis HTML 4.01 publié en décembre 1999. Elle représente donc un grand pas, mais dans quelle direction?

Eric van der Vlist, Dyomedea (vdv@dyomedea.com).
jeudi 31 janvier 2008

See also the English version of this article on my blog.

Table des matières

HTML 5 n'est pas HTML 4 + 1

Retour sur l'histoire de HTML

HTML 5 ou XHTML 2.0?

Des missions très proches

XHTML 5 n'est qu'un mauvais alibi

HTML 5 coupe les ponts avec SGML

Des approches techniques opposées

Seul XHTML 2.0 est extensible

Approche document ou approche application?

Que le meilleur gagne?

HTML 5 n'est pas HTML 4 + 1

Beaucoup d'encre électronique a déjà coulé depuis l'annonce de cette publication et je ne reviendrai pas sur la liste factuelle des différences entre HTML 4 et HTML 5 dont vous trouverez un résumé dans le carnet web de Laurent Jouanneau.

Ces différences sont également exposées dans l'un des documents de la spécification HTML 5 mais curieusement cette liste détaillée se concentre sur le détail des différences syntaxiques sans évoquer les différences de fond.

Ces différences sont pourtant clairement visibles dès l'introduction :

"Le langage de balisage du World Wide Web a toujours été HTML. HTML a été conçu principalement comme un langage pour décrire sémantiquement des documents scientifiques bien que sa conception générale et ses mises à jours successives lui aient permis d'être utilisé pour décrire de nombreux autres types de documents. Le principal domaine n'ayant pas été correctement spécifié par HTML est décrit de manière vague comme celui des applications web. Cette spécification tente de corriger cela tout en mettant à jour les spécifications HTML pour rectifier les problèmes signalés ces dernières années."

Cette introduction éclaire de manière lumineuse le reste de ces spécifications : il s'agit de passer d'une logique de documents à une logique d'applications et ce point est confirmé à plusieurs autres endroits, comme par exemple la section intitulée "Relations avec XUL, Flash, Silverlight, et autres langages propriétaires de description d'interfaces utilisateurs" :

"Cette spécification est indépendante des nombreux langages de description d'interfaces utilisateurs propriétaires. Tout en étant ouvert et indépendant de tout fournisseur, HTML fournit une solution aux même problèmes sans risque de blocage par un fournisseur."

Pour comprendre cette évolution, il faut remettre les choses dans leur contexte.

HTML a effectivement été créé pour représenter des documents. Son succès vient de sa neutralité : bien que l'on puisse prétendre comme j'aime à le faire, que le Web 2.0 n'est que le Web comme il aurait toujours du être, les créateurs de HTML ne pouvaient pas avoir imaginé tout ce que peuvent faire les applications web modernes. Si ces applications sont possibles, c'est parce que HTML n'a pas cherché à spécifier ce qu'était une application web et qu'il est suffisamment générique pour décrire à la fois les applications du web du vingtième siècle, celles du web d'aujourd'hui et très vraisemblablement celles du web de demain.

A l'inverse, si HTML 4.01 avait cherché en 1999 à spécifier ce qu'était une application web, il y a toutes les chances que cette spécification aurait du être contournée pour permettre au Web 2.0 de se développer et que cela ait pu contribuer à ralentir voir bloquer son développement.

En ce sens, je fais à HTML 5 le même reproche que je fais à W3C XML Schema : celui de vouloir spécifier l'utilisation que l'on attend d'un document au risque de limiter la créativité et d'accroître le couplage entre applications.

Alors que l'idée que les applications peuvent être conçues comme des documents tend à s'imposer comme une évidence, HTML 5 cherche au contraire à concevoir les documents comme des applications ce qui me semble être un grand pas... en arrière!

Retour sur l'histoire de HTML

Un autre point qui mérite d'être souligné sont les relations entre HTML 5 et XML en général et XHTML en particulier.

HTML 5 se présente comme étant à la fois la suite logique de HTML 4.01 et XHTML 1.1 et en concurrent de XHTML 2.0.

Sans vouloir reprendre l'historique de ces langages, pour comprendre la situation, il faut revenir quelques années en arrière...

HTML a été conçu comme un vocabulaire SGML et utilise certaines fonctionnalités qui permettent de réduire la verbosité des documents, c'est le cas par exemple de certaines balises comme <img> ou <link> qui n'ont pas besoin d'être refermées en HTML.

XML a été conçu pour être une simplification de SGML et cette simplification ne permet pas d'utiliser ces fonctionnalités qui réduisent la verbosité des documents.

Après la publication de XML, le W3C s'est donc trouvé avec d'un côté une application (HTML) et d'un autre côté un méta langage (XML) qui étaient incompatibles. Dans un souci de cohérence bien compréhensible, il fut décidé de faire évoluer HTML pour le rendre compatible avec XML en gardant le même périmètre fonctionnel. Le nouveau vocabulaire fut appelé XHTML 1.0 et donna naissance à une version 1.1 gardant les mêmes fonctionnalités mais les découpant en modules pour les rendre utilisables séparément.

Ce travail accompli, le W3C commença des travaux portant sur la modernisation des formulaires de saisie (XForms) puis s'attaqua à une nouvelle version majeure (XHTML 2.0) encore en cours de standardisation.

L'approche semble si logique et la démarche si peu contestable que le W3C a sans doute négligé de vérifier qu'il avait toujours le support de la communauté. Dans l'euphorie qui accompagna la publication de XML 1.0 et l'accord parfait entre Microsoft et ses concurrents, l'intérêt pour HTML maintenu auparavant par la « guerre des navigateurs » étaient retombé et les travaux du W3C autour de XHTML se poursuivirent dans une indifférence quasi générale.

Il faut dire également que l'intérêt pratique de XHTML par rapport à HTML était loin d'être évident pour les développeurs de sites web puisque les fonctionnalités étaient restées les mêmes. Migrer un site vers XHTML représente donc un travail supplémentaire qui ne présente souvent aucun autre intérêt à court terme que de pouvoir afficher fièrement le logo « W3C XHTML 1.x ».

C'est également à cette période que Microsoft abandonna pendant un certain temps tout développement sur son navigateur Internet Explorer et où Netscape transféra le développement de son navigateur à Mozilla.

Les acteurs de la « guère des navigateurs » bien représentés au W3C qui était un de leur champs de bataille laissèrent donc place à de nouveaux acteurs, Mozilla, Opera et Apple/Safari plus jeunes et acceptant sans doute plus mal les lourdeurs des procédures du W3C.

Dans le même temps, les premières applications Web 2.0 donnèrent également un regain de créativité aux développeurs d'applications web et tout ces mouvements s'opérèrent en dehors du W3C. Ce n'est guère choquant puisque la vocation d'un organisme de normalisation comme le W3C est de standardiser et non pas d'innover. Par contre, le W3C n'a pas suffisamment pris la mesure de ces développements et a laissé se creuser un véritable fossé entre ses utilisateurs et ses groupes de travail.

Et lorsque ces utilisateurs menés par Opera, Mozilla et Safari ont ressenti le besoin de voir HTML s'améliorer, plutôt que de participer aux travaux en cours sur XHTML 2.0, ils ont créé un groupe de travail, le WHATWG, à l'extérieur du W3C. C'est ce groupe de travail qui a rédigé les premières versions de HTML 5 ainsi que celles d'une spécification sœur, Web Forms 2.0 destinée à être une amélioration des fonctionnalités de formes de saisie de HTML moins complexe que XForms.

Microsoft restant silencieux, le W3C se voyait donc rédacteur d'une spécification XHTML 2.0 ne semblant pas intéresser grand monde alors que se développait à l'extérieur de ses murs une spécification se réclamant de la tradition HTML et rédigée par les principaux outsiders des navigateurs web.

Lors de la conférence XTech 2007, j'ai eu l'occasion de mesurer, lors d'un débat contradictoire, le fossé qui sépare les deux groupes. d'un côté le groupe de travail XHTML 2.0 dans la continuité à la fois de HTML mais aussi de XML et cherchant à tirer les leçons d'années d'expériences dans le domaine des langages de balisage et de l'autre le groupe de travail WHATWG n'hésitant pas à rejeter XML en tant que tel, se réclamant uniquement de HTML et donnant l'impression de chercher à spécifier le web tel qu'on le connaît aujourd'hui.

Tim Berners-Lee a sans doute jugé ce fossé trop large pour être comblé puisqu'il a pris la décision d'inviter le WHATWG à poursuivre ses travaux au sein du W3C dans un groupe de travail formé pour l'occasion et distinct du groupe de travail XHTML 2.0 qui continue également ses travaux.

HTML 5 ou XHTML 2.0?

Le W3C a donc désormais deux groupes de travail.

Des missions très proches

Le groupe de travail XHTML 2.0 poursuit le développement d'un vocabulaire extensible basé sur XML :

"La mission du groupe de travail XHTML 2 est d'accomplir la promesse de XML de déployer XML sur une large variété de plate-formes en accordant une attention particulière à l'internationalisation, l'accessibilité, la portabilité entre plate-formes, l'utilisabilité et la structuration des documents. Le groupe apportera une pièce essentielle aux contenus riches sur le web en combinant XHTML avec d'autres travaux tels que les mathématiques, les dessins vectoriels, les contenus multimédia synchronisés et les formulaires de saisie en coopération avec d'autres groupes de travail"

Le groupe de travail HTML assure quant à lui la continuité avec les versions précédentes de HTML :

"La mission du groupe de travail HTML, au sein de l'activité HTML est de poursuivre l'évolution de HTML (qui inclut les syntaxes HTML classique et XML)."

La concision de cette phrase n'empêche pas HTML 5 de se vouloir également extensible et indépendant des plate-formes, puisque la liste des livrables indique qu' "il y a un seul livrable, la spécification HTML, conçue de manière indépendante des plate-formes" et que l'on apprend un peu plus loin que "le groupe de travail HTML est encouragé à fournir un mécanisme pour permettre à des vocabulaires développés de manière indépendante tels que Internationalization Tag Set (ITS), Ruby, et RDFa d'être mélangés dans les documents HTML" .

Il s'agit donc bien, au risque de voir se développer une guerre des standards de développer deux spécifications concurrentes et de laisser les utilisateurs choisir.

XHTML 5 n'est qu'un mauvais alibi

On retrouve cette politique au sein même de la spécification HTML qui propose de choisir entre deux syntaxes :

"Cette spécification définit un langage abstrait pour décrire des documents et des applications et des APIs pour accéder à la représentation en mémoire des ressources utilisant ce langage. La représentation en mémoire est appelée "DOM5 HTML", ou "le DOM" pour faire court. Il peut y avoir de nombreuses syntaxes pour représenter des ressources utilisant de langage abstrait dont deux sont définies dans cette spécification. La première de ces syntaxes concrètes est "HTML5". C'est le format recommandé pour la plupart des utilisations. Elle est compatible avec tout les navigateurs historiques. Si un document est transmis avec le type text/html, il devra être traité comme un document "HTML5" par les navigateurs. La deuxième de ces syntaxes utilise XML et est appelée "XHTML5". Quand un document est transmis avec un type XML tel que application/xhtml+xml, il doit être analysé avec un parseur XML et traité par les navigateurs comme un document "XHTML5". Nous rappelons aux auteurs que le traitement de XML est différent du traitement de HTML et que notamment, même les erreurs de syntaxe mineures empêchent un document XML d'être affiché de manière complète alors qu'elles seraient ignorées avec la syntaxe "HTML5"."

Cette section, heureusement non normative, semble exclure qu'un navigateur puisse accepter un document HTML autre que HTML5 ou XHTML autre que XHTML5! Et avec une telle mise en garde, on se demande quel auteur va choisir le syntaxe XML...

Cette mise en garde repose d'ailleurs sur une incompréhension hélas assez commune de la recommandation XML. On entend effectivement souvent dire que l'analyse syntaxique d'un document XML doit s'arrêter à la première erreur, mais la recommandation est en fait beaucoup plus souple que cela. Elle distingue deux types d'erreurs :

  1. Les erreurs simples sont "une violation des règles de cette spécification. Sauf spécification contraire, le non respect d'une règle de cette spécification indiquée avec un verbe DOIT, EXIGE, NE DOIT PAS, DEVRAIT et NE DEVRAIT PAS est une erreur. Les logiciels conformes PEUVENT détecter et signaler les erreurs et PEUVENT les corriger."
  2. Les erreurs fatales sont "une erreur qu'un processeur XML conforme DOIT détecter et signaler à l'application. Après avoir rencontré une erreur fatale, le processeur PEUT continuer le traitement des données pour rechercher d'autres erreurs et PEUT signaler ces erreurs à l'application. Pour assurer cette correction, le processeur PEUT rendre les données brutes en provenance du document (mélangeant texte et balisage) disponible à l'application. Néanmoins, lorsqu'une erreur fatale est détectée, le processeur de DOIT pas continuer son traitement normal (c'est à dire qu'il NE DOIT PAS continuer à transmettre les informations sur le contenu textuel et la structure du document à l'application de manière normale)."

On voit que la recommandation XML précise au contraire qu'un processeur XML peut corriger les erreurs simples. On peut argumenter sur le fait que ce que la recommandation XML appelle erreur fatale peut être considéré par un auteur comme une erreur mineure (ce peut être le cas par exemple lorsqu'une balise <img> n'est pas refermée), mais même en cas d'erreur fatale, la recommandation n'impose pas d'arrêter tout traitement. Elle impose de signaler l'erreur à l'application (le navigateur dans le cas d'un document lu sur le web) mais elle ne spécifie pas la manière dont le navigateur doit réagir et permet de continuer l'analyse du document pour peu que ce ne soit pas de manière « normale ».

Un navigateur qui déciderait de basculer dans un mode d'analyse dégradé après détection d'un erreur fatale pour continuer à afficher le document serait donc parfaitement conforme à la recommandation XML.

Si les navigateurs réagissent de manière aussi stricte aux erreurs d'analyse des documents XML, cela ne vient donc pas d'un souci de respect de la recommandation, mais d'un souhait de la communauté XML au moment où ces navigateurs ont introduit le support de XML. On sortait alors de la guerre des navigateurs entre Microsoft et Netscape et tout le monde déplorait que pour supporter les extensions introduites de manière sauvage, les navigateurs en étaient venus à accepter à peu près n'importe quel document aussi peu conforme aux spécifications soit-il et à afficher les non conformités de manière spécifique parce que non documentée.

En réaction à ce laxisme, il y a eu un consensus quasi absolu lorsque les navigateurs ont décidé de s'arrêter à la première erreur rencontrée dans un document XML comme la recommandation leur permet mais ne leur impose pas de le faire.

Si cette position doit être assouplie, il serait dommage de rejeter XML puisque nous avons vu qu'elle n'est en aucun cas imposée par la recommandation.

La manière dont sont présentées ces deux syntaxes laisse clairement supposer que la mention de la syntaxe XML qui n'était pas mentionnée dans les premiers travaux du WHATWG est un compromis permettant d'éviter à une recommandation W3C de tourner le dos à XML mais que le but est bel et bien de maintenir et promouvoir l'utilisation d'une syntaxe non XML.

HTML 5 coupe les ponts avec SGML

Non content de s'affranchir de XML, HTML 5 abandonne également toute recherche de compatibilité avec SGML puisque la spécification indique que "bien que la syntaxe HTML de HTML5 ressemble à SGML et XML, il s'agit d'un langage différent avec ses propres règles d'analyse syntaxique" .

Cette phrase est caractéristique de l'attitude générale de la spécification qui donne l'impression de vouloir se bâtir sur l'expérience du web en ignorant celle des langages de balisages au risque là encore, de geler le web tel que nous le connaissons aujourd'hui.

L'attitude du groupe de travail XHTML est plus mesurée. Il s'agit bien entendu de prendre en compte les évolutions du web mais en utilisant des approches qui tiennent également compte de l'expérience acquise en développant d'autres vocabulaires XML ou SGML.

Des approches techniques opposées

Sans entrer dans une comparaison en détail des spécifications HTML 5 et XHTML 2.0, deux points méritent notre attention.

Seul XHTML 2.0 est extensible

Les deux spécifications reconnaissent la nécessité de mieux prendre en compte les besoins apparus depuis la création de HTML lorsqu'ils ne sont pas déjà pris en compte, mais la manière de le faire est totalement différente.

Pour HTML 5, la démarche a l'apparence de la simplicité : lorsqu'on reconnaît un nouveau besoin on ajoute un nouvel élément. Puisque beaucoup de pages web sont utilisées pour publier des articles (au sens large), on ajoute un élément <article>. Puisque beaucoup de pages web ont des barres de navigation on ajoute un élément <nav>....

On a pourtant vu avec les grands vocabulaires utilisés dans le domaine de la documentation quelles sont les limites de cette approche : elle conduit à une explosion du nombre d'éléments et ce qui était simplicité se transforme en complexité. Il devient difficile de choisir quel élément utiliser et comme ces éléments sont spécialisés, ils ne correspondent presque jamais exactement à ce que l'on cherche à faire.

Appliquer cette approche à HTML revient à plus ou moins long terme à le transformer en un clone de DocBook pour le web...

L'approche du groupe de travail XHTML 2.0 est totalement opposée. Elle propose au contraire de faire le ménage dans la liste des éléments XHTML tels que nous les connaissons et à supprimer tout ceux qui ne sont pas vraiment nécessaires.

Elle s'appuie ensuite sur l'observation des pratiques actuelles : comment fait-on aujourd'hui pour représenter un article ou une barre de navigation? L'approche la plus commune est d'utiliser des éléments standards, tels que l'élément «<div>, et d'identifier ces élément par leur attribut « class » pour leur appliquer un style CSS ou une animation JavaScript.

L'inconvénient de cette approche est que les classes utilisées ne sont pas standardisées et que cela constitue un détournement de la fonctionnalité de l'attribut « class » utilisé pour qualifier la signification d'un élément plutôt que la manière dont il doit être présenté à l'écran. Ce détournement est devenu chose courante, puisqu'il est à la base de l'approche des microformats.

Pour éviter ce détournement tout en gardant la souplesse de cette approche, XHTML 2.0 propose d'introduire un attribut « role » permettant de définir le rôle des éléments XHML.

Cet attribut peut prendre un certain nombre de valeurs standards, définies dans la spécification (« navigation » par exemple pour une barre de navigation) mais peut également prendre d'autres valeurs différenciées par le mécanisme des espaces de noms XML.

Par ce biais, on peut donc introduire les mêmes fonctionnalités que HTML 5 en évitant de créer de nouveaux éléments. Ce mécanisme est plus extensible puisque n'importe qui peut créer de nouveaux rôles en utilisant de nouveaux espaces de noms. Cela donne également aux microformats le moyen de se développer sans détourner l'attribut « class » qui peut reprendre sa fonction initiale et ne définir que la présentation des éléments.

Approche document ou approche application?

Le second point notable sur lequel les deux spécifications divergent est dans leurs relations entre données et applications ou traitements.

XHTML 2.0 s'appuie non seulement sur la syntaxe mais sur l'architecture XML qui consiste à superposer les couches suivantes :

  1. Au plus bas niveau, on définit les règles syntaxiques, c'est à dire les recommandations XML et espaces de noms.
  2. Au dessus de ces règles, on définit un modèle de données : l'infoset XML indépendant de tout traitement.
  3. S'appuyant sur ce modèle de données, on définit ensuite des interfaces et des langages spécifiques (DOM, XPath, XQuery, ...) et des langages de schéma (W3C XML Schema, RELAX NG, Schematron, ...).

Cette architecture a mis du temps à se construire et historiquement les choses n'ont pas toujours été aussi simple, mais elle dissocie totalement données et traitements et permet un couplage lâche entre applications.

Nous avons vu que HTML 5 se coupe volontairement de ses racines XML et SGML. Cela signifie également que cette spécification ne s'appuie pas sur cette architecture et au contraire, elle mélange les aspects syntaxiques, modèle de données et interface (DOM) dans une seule spécification sous un prétexte de simplicité.

Cette conception est liée au fait que HTML 5 se présente, nous l'avons vu en introduction, comme un format permettant de développer des applications web. On ne parle plus de documents mais bien de développement d'applications.

La différence me semble importante notamment en matière de pérennité : les documents sont transformables et réutilisables et tout le monde s'accorde à dire que l'utilisation de XML est la meilleure garantie pour la conservation à long terme des documents. Il n'en va pas de même des applications. Une application HTML 5 combinant du texte, du balisage et une bonne dose de JavaScript a t-elle la même pérennité qu'un document XHTML 2.0? J'en doute fort.

L'architecture XML sur laquelle est bâtie XHTML 2.0 n'empêche pas l'écriture d'applications web, mais elle dissocie plus clairement ce qui est données et ce qui est traitement.

XHTML 2.0 cherche également à promouvoir, notamment au travers de XForms, des méthodes de développement déclaratives mieux adaptées que JavaScript à l'architecture orientée documents à laquelle HTML 5 cherche à échapper.

Que le meilleur gagne?

Pour toutes ces raisons, HTML 5 me semble constituer un grand pas en arrière et je considère XHTML 2.0 comme lui étant la seule alternative techniquement viable et souhaitable.

Est-ce que cela signifie pour autant que XHTML 2 va s'imposer et le fait que HTML 5 soit tiré par ceux qui développent les navigateurs de demain ne signifie t-il pas au contraire que c'est HTML 5 qui l'emportera?

XHTML 2.0 semble effectivement avoir un sérieux handicap sur ce plan, mais les dés ne sont pas jetés. Le groupe de travail ne prévoit pas que HTML 5 devienne recommandation avant le troisième trimestre 2010 et d'ici là bien des choses peuvent encore changer.

Il nous revient en tant qu'utilisateurs de faire savoir où va notre préférence en commençant par boycotter les fonctionnalités HTML 5 qu'implémentent déjà certains navigateurs.

A court terme, certifier qu'une page est conforme XHTML 1.x est également un moyen de certifier qu'elle ne contient pas de HTML 5!

Voir aussi :

  1. Vers une nouvelle guerre du Web?
  2. XML, quel historique ?
  3. Web 2.0 : mythe et réalité

Copyright 2008, Eric van der Vlist.


 

Mots clés.



L'histoire de XML s'écrit en ce moment même. XMLfr vous aide à la suivre et à en dégager les tendances.


Les documents publiés sur ce site le sont sous licence "Open Content"
Conception graphique
  l.henriot  

Conception, réalisation et hébergement
Questions ou commentaires
  redacteurs@xmlfr.org