Aller au menu. Aller au contenu.

Nihil addendum
par al.jes

Pourquoi je n'aime pas HTML 5

Cet article, rédigé en juin 2011, fut initialement publié sur Note à moi-même, le journal de Ti-Pierre, puis conjointement sur mon propre blog. Mon avis quant au HTML 5 ayant peu changé, je vous le livre tel quel. N’hésitez surtout pas à participer au petit débat qu’il occasiona lors de sa première publication, cela me fera grand plaisir.


C’était il y a bientôt huit ans — un dimanche matin d’octobre 2003 — que j’ai fait ma première rencontre avec HTML. Je venais de pousser la porte d’une association ayant vocation de partager le goût des sciences pour participer à une activité de création de sites web.
Quelques années plus tard, j’ai appris que j’utilisais la quatrième version du langage HTML et qu’il en existait une évolution nommée xHTML (x pour extensible). Avec xHTML 1.0, puis 1.1, j’ai appris de nouveaux concepts comme la séparation du contenu et de la présentation, la sémantique d’un code ; j’ai appris un nouveau langage (CSS, pour la présentation) ; ma syntaxe est devenue plus rigoureuse et j’ai désappris de nombreuses mauvaises pratiques, même si je ne comprenais pas toujours pourquoi c’en était (fort heureusement, j’ai eu l’occasion d’y repenser, et de comprendre mon erreur).

Quelques années ont encore passé, et j’ai découvert que le W3C — World Wide Web Consortium, l’organisme qui gère (x)HTML et quelques autres standards en vigueur sur le web — préparait HTML 5, originellement un projet de différents éditeurs de navigateurs web, et xHTML 2, plus tard abandonné au profit du premier. Je ne m’y suis pas intéressé tout de suite, ces deux évolutions possibles n’étant ni finalisées ni implémentées dans la plupart des navigateurs, a fortiori dans les navigateurs les plus utilisés. Mais cela fait un an ou deux que la donne a changé : les navigateurs mettent fortement en avant HTML 5, présenté comme le futur du web. J’ai alors été un temps très enthousiaste, HTML 5 laissant de superbes perspectives pour l’avenir…
Pourtant, HTML 5 me hérisse le poil. Pourquoi ?

HTML ?

Tout d’abord, HTML signifie « hypertext markup language » soit, dans la merveilleuse langue de Rabelais, « langage hypertexte à balisage » ; chaque mot a son importance :

« Qu’il s’occupe de texte et de liens »… Tiens, tiens, certaines des grosses nouveautés d’HTML 5 ne serait-elle pas la gestion de l’audio et de la vidéo, des formulaires plus poussés ? Ça ne serait pas hors sujet par hasard ? Je vous entends déjà…

Ouais, mais c’est cool, parce que du coup on a tout en un !

Ouais, mais non. Paf !

Bon, d’accord, c’est pas très argumenté comme réponse, alors voici : quand on définit un objectif, il serait bon de s’y tenir. C’est pour cette raison que l’on a pris l’habitude de distinguer le contenu de la présentation, limitant xHTML à la structuration d’un texte accompagné de liens (et, on y reviendra, de quelques autres choses ayant une valeur sémantique) et faisant appel au CSS, un autre langage, pour gérer l’affichage plus ou moins esthétique de notre contenu. En quelque sorte, ce que je demande ici, c’est de reprendre cette habitude unixienne de l’application qui ne fait qu’une chose mais qui la fait bien. Les informaticiens appellent cela le principe KISS (pour « keep it stupid simple », « garde ça stupidement simple »).

Ouais, mais on va pas non plus apprendre trouze mille langages différents !

Oui et non…
De un, on apprend déjà plusieurs langages, voyez plutôt : (x)HTML pour le contenu, CSS pour la présentation, PHP pour les automatismes côté serveur, MySQL pour la gestion de bases de données, JavaScript pour les automatismes côté navigateur, etc. Ça ne nous dérange pourtant pas tant que ça… Certes, c’est un peu plus compliqué au début, parce qu’il faut apprendre, mais ça ne nous empêche pas de trouver au final que ce nouveau langage est bien plus adapté à l’usage que l’on en a qu’un fourre-tout infâme, non ?
De deux, xHTML (1.0, 1.1 et 2) est un dialecte XML, c’est-à-dire un langage ayant son vocabulaire propre mais utilisant la syntaxe XML, et il y a des dialectes XML pour à peu près tout. Donc si l’apprentissage d’une nouvelle syntaxe vous fait peur, pas d’inquiétude, il suffit de prendre un autre dialecte XML ! et si c’est le nouveau vocabulaire qui vous fait peur, alors l’ajout de vocabulaire au sein du même langage aura exactement le même effet… De trois, XML, qui veut dire « extensible markup language » (« langage de balisage extensible »), permet parfaitement d’utiliser plusieurs de ses dialectes au sein d’un même document, ce qui nous laisse un potentiel infini, donc bien plus grand que d’avoir un nombre de possibilité finies au sein du même « dialecte »…

Ouais, mais, de toute façon, (x)HTML ne se limitait déjà pas à l’hypertexte !

En effet, mais ça veut pas dire que c’est une bonne chose, non ? D’ailleurs, si on en est à utiliser ce genre d’arguments, ça fait tout de même un moment que le W3C cherche à « épurer » (x)HTML, non ? Je veux dire, xHTML 1.0 a viré tout ce qui s’occupait de la présentation, xHTML 1.1 a viré les « frames », xHTML 2 virait les formulaires… Pour sûr, xHTML 2 n’était pas parfait sur ce point non plus, mais il y avait un progrès notable.

Mais alors… Que faire ?

xHTML 2 me semble être un bon point de départ, notamment pour l’universalisation de l’attribut href (tout peut être lien) et la création de l’attribut universel role (tout est sémantique). Ensuite, on peut enlever la balise <img> au profit de <object>, voire supprimer ces deux éléments au profit d’un dialecte XML spécialisé dans l’intégration de fichiers (qui pourrait alors aller plus loin que la balise <object>…). On peut également supprimer l’élément <a>, qui ne sert plus à rien (tout peut être ancre grâce à l’attribut universel id et tout peut être lien comme dit ci-avant). Pour finir, on peut supprimer les éléments <h1>, <h2>, <h3>, etc. au profit de la nouvelle structure proposée par xHTML 2, structure qui fonctionne par imbrication de <h> et de<section> (n’utiliser qu’une seule structure me paraît plus simple, et cette nouvelle structure d’une part ne se limite pas à six niveaux de titre et d’autre part est clairement structurelle, alors que l’on pouvait penser en terme de présentation avec l’ancienne structure).

XML ?

HTML 5 n’est pas, on l’a vu, un dialecte XML. Cependant il existe x/HTML 5, qui se veut être une implémentation XML de HTML 5. Ah, on est sauvés alors ! Eh bien allons-y, commençons notre code comme tout document XML qui se respecte : par la déclaration XML.

<?xml version="1.0" encoding="UTF-8"?>

Cette ligne de code veut tout simplement dire la prase suivante :

Hé, toi, l’agent utilisateur ! Oui, toi ! Ce document, là, tu vas me l’interpréter selon la syntaxe XML, dans sa version 1.0. Et tant que j’y suis, le texte est en Unicode (UTF-8).

À noter que dans votre cas, l’agent utilisateur sera certainement votre navigateur…

Voilà, on rajoute un peu de x/HTML 5, pour obtenir le code suivant :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
    <head>
        <title>Mon super code x/HTML 5</title>
    </head>
    <body>
        <p>Super, je code en x/HTML 5 !</p>
    </body>
</html>

On envoie le tout à Unicorn, le service de validation du W3C, pour vérification. Pour info, le W3C a créé XML, donc on peut supposer qu’un code XML correctement rédigé devrait passer. Il y a quelques mois ça ne passait pas, mais d’une part Unicorn était en test (avant, le W3C utilisait d’autres services similaires) et d’autre part les travaux sur HTML 5 (qui n’est, je le rappelle, toujours pas finalisé) étaient moins avancés. Le test est concluant puisque Unicorn nous dit ça :

This Page Is Valid HTML5!

Traduction : « T’es un bon garçon, ton code est correct ».

Maintenant, le W3C étant un organisme indépendant et pour diverses raisons concernant le doctype (voir partie suivante), nous pouvons douter que notre navigateur lira correctement ce code. Comme je suis un garçon retors, on ne va pas se contenter d’afficher ça sous différents navigateurs : on va plutôt faire appel à un autre service de validation. Mais pas n’importe lequel : validator.nu, le service de validation du WHAT Working Group (un groupe de pression travail fondé et soutenu par différents éditeurs de navigateurs ou acteurs du « cloud computing » (expression barbare qu’il convient de traduire par « tu donnes toutes tes données, on les revend à des publicitaires, des entreprises douteuses et des états à tendance dictatoriale (surtout si vous y habitez), et tu dis adieu à ta vie privée »), c’est l’initiateur de HTML 5). Là, le test nous donne ceci :

Error: Saw <?. Probable cause: Attempt to use an XML processing instruction in HTML. (XML processing instructions are not supported in HTML.)

Traduction : « Toi, t’as confondu x/HTML 5 avec un dialecte XML. Faudrait pas trop en demander mon garçon ! »

Warning: Comments seen before doctype. Internet Explorer will go into the quirks mode.

Ah. Je savais pas que le rôle d’un service de validation était de nous demander de garder nos mauvaises pratiques pour encourager les navigateurs indignes de ce nom dans leurs erreurs… Je prends note.

Error: When the attribute xml:lang in no namespace is specified, the element must also have the attribute lang present with the same value.

Je confirme, ne pas confondre x/HTML 5 avec un dialecte XML, c’est juste de la poudre aux yeux pour faire croire qu’on écoute un peu le W3C. Note à moi-même : le W3C est mort, WHAT Working Group l’a remplacé.

Là, la solution est très simple : utiliser un vrai dialecte XML, ou ne pas prétendre faire du XML. Un peu d’honnêteté, quoi… Dans mon cas, ça sera très simple : je ne veux pas (plus) utiliser HTML 5.

Doctype ?

Quand je codais encore en HTML 4, je n’utilisais pas de doctype. Ça marchait tout aussi bien (vu que le non respect des standard était à l’époque la norme sur les navigateurs) et j’avais pas à me prendre la tête. Quand je suis passé au xHTML, je trouvais que c’était compliqué, mais c’était nécessaire d’avoir un doctype, et le bon. Donc je copiais-collais le doctype que me conseillais le service de validation xHTML du W3C. Pour info, un doctype en xHTML, ça ressemble à ça :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
    "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

Puis est arrivé HTML 5 et son doctype simplifié, qui ressemble à ça :

<!DOCTYPE html>

Sur le coup, j’étais super content : enfin un doctype que je pouvais retenir ! Et puis je me suis demandé à quoi servait le doctype, et pourquoi il était si compliqué… Et quand je suis tombé sur le doctype du xHTML 2, ressemblant fortement à ceux des xHTML 1.0 puis 1.1, j’ai décidé de le décortiquer.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 2.0//EN"
    "http://www.w3.org/MarkUp/DTD/xhtml2.dtd">

Nous avons donc :

À savoir, les déclarations de type de document (DTD) ont été créées pour SGML, l’ancêtre de XML. Un autre outil a été développé pour XML : les schémas XML, plus complexes, mais plus puissants. En revanche, pour en appeler un, il suffit d’employer un espace de nom au sein de l’élément racine du document, comme ceci :

<html xmlns="http://www.w3.org/1999/xhtml"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.w3.org/1999/xhtml
    http://www.w3.org/MarkUp/SCHEMA/xhtml2.xsd"
    xml:lang="fr">

J’ai mis ici une balise d’ouverture de l’élément racine de xHTML 2, avec un espace de nom (xmlns) principal renvoyant vers le schéma XML du xHTML et un espace de nom secondaire que j’ai nommé « xsi » et renvoyant vers le schéma XML de XMLSchema-instance. L’utilité de ce dernier est de préciser exactement l’emplacement du schéma XML, puisque xHTML 2 n’étant pas finalisé son schéma n’est pas celui par défaut pour xHTML. J’ai donc précisé l’emplacement du schéma grâce à l’attribut schemaLocation placé dans l’espace de nom « xsi », puis j’ai spécifié la langue de mon document (l’espace de nom « xml » est implicite et existe dans tout document XML, il n’y a donc pas besoin de le déclarer).

Les schémas XML peuvent aussi bien être une alternative à la DTD qu’en être complémentaire, cela dépendra du dialecte employé.
Petit détail pour les plus curieux, une DTD utilisera une syntaxe spécifique aux DTD, alors qu’un schéma XML est… un dialecte XML !

Mais en HTML 5, point de schéma. On en trouve un tout petit en x/HTML 5, mais qui ne fait qu’adapter deux trois détails pour la syntaxe XML (oui, je suis de mauvaise foi, et j’assume). Donc le tout est dans le doctype.

Ah oui, mais t’avais pas dit que le doctype de HTML 5 il ressemblait à ça ?

<!DOCTYPE html>

Gagné ! On a strictement aucune information sur l’emplacement de la DTD, absolument rien, si ce n’est son nom !

Petit rappel historique maintenant : si la dernière décennie a vu le respect des standards se généraliser sur le web (essentiellement grâce à la rigueur de la syntaxe XML et aux efforts de la fondation Mozilla), ça n’était pas le cas des années 90, qui ont connu ce qu’on a appelé par la suite la « guerre des navigateurs ». Et cette guerre n’avait rien d’épique : les éditeurs de navigateurs, visant clairement le monopole, se battaient à coup d’éléments non standards spécifiques à leurs navigateurs. Les plus anciens se souviendront sans doute de cette balise que je n’ose nommer qui fait clignoter du texte (bon goût s’abstenir, mais il faut croire qu’en cette décennie-là bien peu étaient ceux à avoir du goût… si vous voyez certains des sites que j’ai développé à l’époque !), spécifique à IE… Mais il y en avait d’autres, des balises spécifiques à Netscape, à Mosaic, à IE… Et tout ça était rendu possible par l’absence de DTD unique dont l’emplacement est clairement spécifié.

Vous voyez un peu l’idée ? On n’a plus d’appel à une DTD, juste un doctype fantoche… Vous voulez revenir à l’époque des balises spécifiques ? À l’époque où l’on code des sites accessibles pour 100 % des visiteurs potentiels, vous voulez vous retrouver avec des sites faits exprès pour tel navigateur couvrant 50 % de vos visiteurs potentiels tout au plus (ne pas se fier aux parts de marchés, qui ne prennent en compte que les navigateurs « ordinaires », et non les navigateurs spécifiques à tel ou tel handicap) ? Personnellement, mon choix est fait, et c’est clairement non.

Et j’entends déjà ceux qui me dirons qu’on a pas forcément besoin qu’un site soit accessible à tous, à quoi je répondrai que si : il n’y a pas de raison pour qu’un handicapé, en plus de son handicap, doive subir que l’on ne l’ignorât. Et ce sont souvent les premiers oubliés quand on ne pense pas un code en terme d’accessibilité.

Pour finir sur ce point, l’absence de DTD unique pose déjà problème : les services de validation ont pour rôle de dire si l’on respecte ou non les spécifications du langage ou dialecte employé. Pour ce faire, ils s’appuient sur les DTD et les schémas XML. Quand ces derniers sont absents, ils se doivent de faire de la rétro-ingénieurie. Le résultat est donc forcément imparfait. C’est pour cela que dans la partie précédente on ne s’était pas contentés d’un seul service de validation pour vérifier la conformité du code.

Avenir ?

Nous venons donc de voir que HTML 5, présenté comme l’avenir du web, revient sur de très nombreuses avancées, comme la simplification du langage, XML et son énorme potentiel, la mise en conformité avec une DTD unique permettant de simplifier le travail des développeurs, etc.
D’ailleurs, si l’on revient sur ce dernier point, la simplification du code aurait permis un accès pour tous à la programmation, ce qui consisterait tout de même à une révolution au moins aussi majeure que la popularisation de l’accès à Internet, qui donnait à tous la possibilité de publier ! Je pense donc sincèrement que les professionnels du « cloud computing » et les éditeurs de navigateurs ont sauté sur l’occasion pour pérenniser leur statut d’experts, un peu comme Microsoft, qui il n’y a pas si longtemps traitait le Logiciel Libre de « cancer »… Après tout, il ne faut pas oublier que le code est leur gagne-pain, et s’ils ne sont pas forcément malhonnêtes, loin de là, ils ne voient pas forcément d’un bon œil que M. Tout-le-monde puisse se mettre à coder.

Mais revenons-en à notre propos : HTML 5 revenant sur de nombreuses avancées. HTML 5 revient également sur un point cher à de très nombreux développeurs : le concept de séparation entre le contenu et la présentation. Ce concept, à première vue un peu abstrait, est en fait très simple : lorsque l’on rédige une page on se concentre sur le sens de ce que l’on code, sans se préoccuper de l’apparence que notre contenu aura. Cela permet entre autre de pouvoir modifier l’apparence sans modifier le contenu, d’avoir plusieurs contenus avec la même présentation (sans la re-coder intégralement) ou, lorsque l’on veut modifier l’apparence de plusieurs contenus ayant la même apparence, de ne la modifier qu’une fois et pas autant de fois que le nombre de contenus. En bref, c’est extrêmement pratique.

Comment revenir sur ce point, après tout les gens peuvent continuer d’utiliser CSS pour leur présentation ?

Eh bien c’est assez insidieux : on reprend les éléments de HTML 4 conçus pour la présentation (et qui avaient disparus avec xHTML 1.0), et on les présente sous un nouveau jour, en leur prétendant une valeur sémantique.

Je vais ici prendre l’exemple de l’un de ces éléments, <i>, mais l’idée est la même pour <b>, <small> ou encore <font> (oui, <font> !).

En HTML 4, un texte placé entre <i> et </i> était affiché en italique. En HTML 5, voici ce que le W3C nous dit :

The i element now represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose in a manner indicating a different quality of text, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name in Western texts.

Ce que xhtml.com traduit par :

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.

Analysons maintenant.

Ce sont donc certes un ensemble de choses que l’on aurait tendance à écrire en italique, mais l’italique n’est pas obligatoire, c’est seulement une façon comme une autre d’exprimer l’emphase. Merci de ne pas confondre sens et présentation habituelle de tel ou tel sens.

Mais, mais… Pourquoi revenir sur ce concept, alors qu’il semblait si pratique ?

Eh bien c’est un mystère… Je ne m’explique vraiment pas ça, d’autant plus que la séparation entre contenu et présentation peut sembler à première vue compliquée, et donc rebuter, et donc renforcer le statut d’experts des auteurs de ce langage…
L’explication officielle c’est de permettre la rétro-compatibilité avec HTML 4, mais d’une part la rétro-compatibilité ne serait réelle que si les définitions des éléments étaient inchangées, ça n’est pas le cas, et d’autre part c’est aux agents utilisateurs, et non aux spécifications elles-même, d’assurer la rétro-compatibilité, par exemple en interprétant plusieurs spécifications.

W3C ?

Il y a encore deux ou trois ans, le W3C travaillait sur xHTML 2, contre l’avis des éditeurs de navigateurs qui trouvaient le changement trop grand. Des critiques ont également été formulées à l’encontre du processus de développement de xHTML 2 qui était, et j’approuve, bien trop fermé. Seulement, là où le changement m’enthousiasmait (voire me semblait insuffisant) et où une ouverture du processus de développement m’aurait suffit, Apple Inc, la fondation Mozilla et Opera Software ASA. ont préféré créer un groupe de travail informel (le WHAT Working Group n’a pas d’existence juridique) et développer une nouvelle technologie complètement timorée et rétrograde. Chacun sa méthode.

Par la suite, le W3C a cédé aux pressions du WHAT Working Group — ou plutôt de ses membres (je rappelle et insiste : ce groupe n’a pas d’existence juridique) — et a créé un groupe de travail interne pour participer au développement de HTML 5. Puis le W3C a cessé le développement de xHTML 2. Un regroupement d’éditeurs de navigateurs — vite rejoint par d’autres éditeurs de navigateurs et par des acteurs du « cloud computing » — venait de court-circuiter le vénérable W3C.

Une idée a commencé à germer en moi il y a quelques mois. Il existe un autre groupe, informel, sans existence juridique, qui a de l’importance sur Internet. Ce dernier ne se contente pas du web, mais l’englobe. Ce dernier est entre autres responsable de protocoles allant de IP (pour internet protocol, c’est ce qui permet d’identifier une machine connectée à Internet) à XMPP (pour extensible messaging and presence protocol, un protocole permettant entre autres de faire de la messagerie instantanée, de gérer un micro-blog…) en passant par oAuth (un protocole permettant une connexion sécurisée à tel ou tel service). Bref, ce dernier pourrait parfaitement prendre en charge ce qui ne va plus chez le W3C. Ce dernier, c’est l’IETF. Cependant, ça n’aura aucun impact si je suis seul à leur réclamer l’ouverture d’un groupe de travail pour développer xHTML 2 (et je n’ai ni le temps ni les compétences pour développer moi-même la spécification et un agent utilisateur l’interprétant…).
Du coup, je sens que ça va rester à l’état de vœu pieu…

En attendant, je peux toujours continuer à utiliser xHTML 1.1, et je ne m’en priverai pas.


Pour aller plus loin…

Vous pouvez trouver mes sources ainsi que quelques ressources supplémentaires dans la liste qui suit :

Voilà ! J’en profite pour remercier Ti-Pierre de m’avoir proposer d’écrire cet article, ainsi que Poupi et Dhoko qui m’ont inspirés – grâce aux débats que j’ai déjà eu avec eux sur le sujet.

Publié le 30.12.2012. Lien permanent. Retourner en haut.

©2012 – al.jes, certains droits réservés
Réagissez ! Écrivez-moi : me @ aljes.me