On croyait que le feuilleton s'était définitivement arrêté, mais non, voilà que la dramaturgie du soap des normes du web revient en force : Le W3C et le WHAT-WG sont repartis pour se faire la gueule, et les standards HTML vont à nouveau exploser.

TL;DR ? Ben si tu connais l'histoire, tu peux sauter direct au dernier rebondissement.

D'abord, ré-expliquons comment on en est venu au HTML5

Les débuts du HTML

Le HTML était donc basé sur le SGML, un format de langage descriptif adopté dans l'Union Européenne durant les 1980s pour son interopérabilité. C'est donc fort naturellement en tant que scientifique employé au CERN à Genève, important site de recherche financée par l'Europe, que Tim Berners-Lee a basé son navigateur web sur le SGML. Et ceci alors qu'existaient d'autres langages descriptifs déjà plus complets comme le TEX.

Sir Tim Berners-Lee honoré lors de la cérémonie d'ouverture des JO de Londres Vendredi dernier
1207-HtmlWars-Sir-Tim-Berners-Lee-008.jpg
Photo reprise de The Guardian, © Emmanuel Dunand pour l'AFP

Au moment de la Guerre des Navigateurs, Microsoft était arrivé à s'imposer en gagnant la bataille des would-be developers. Le moteur de rendu de Internet Explorer était incroyablement laxiste. Imaginez que d'un coup, vous n'aviez plus à quoter les attributs, que les balises étaient très rarement fermées, mais avec MSIE, vous n'étiez même plus obligés de fermer les tags, ça passait quand même !

Un code aussi aberrant que <table<td align=center>truc<td>machin</tr></html> passait quand même ! Et il devenait nettement plus facile de faire du site web pour MSIE que pour Netscape.

Or, le HTML commençait à être utilisé en dehors des navigateurs, et il était hors de question de laisser un langage descriptif devenir trop laxiste au point de ne plus être exactement sûr du rendu. D'où la demande d'autres acteurs souhaitant le normer pour l'utiliser d'une manière stable.

Et c'est là qu'on parle W3C

Quand Tim Berners-Lee a fondé le W3C en 1994, on commençait à voir poindre plusieurs navigateurs développés par des sociétés différentes, et chacun avec son moteur de rendu. Mais le laxisme d'interprétation de MSIE 3 puis 4 s'accordait très mal avec un langage qui commençait à être incorporé en dehors des navigateurs web. Rappelons que le HTML décrit l'information d'une page en la classant par son importance. Théoriquement, le document s'articule autour des balises headings de <H1> à <H6>.

L'arrivée des spiders des moteurs de recherche comme Altavista laissait entrevoir l'importance des agents intelligents qui ont besoin d'une interprétation sémantique forte. C'est pour ça que le W3C a commencé à réfléchir à séparer le fond (l'arbre sémantique du document) de la forme, ce qui allait devenir les CSS. D'autres logiciels commençaient à utiliser le balisage HTML, et des fois totalement en dehors du protocole web : la radio numérique DAB l'a embarqué comme format de métadonnées en 1998, et à la même époque, il y a eu des expériences en télévision pour remplacer le télétexte (ce qui préfigurait le HbbTV 15 ans avant),…

Où le XML est apparu

C'est pour ça qu'en 1998 fut défini la grammaire de base du XML : avoir plus de souplesse sémantique que le HTML, mais exiger une écriture où :

  • Le document doit commencer par une balise <?xml ?> indiquant la nature xml, et éventuellement la version et le charset. Par exemple :
    <?xml version="1.0" encoding="UTF-8" ?>
  • Le document doit inclure un lien vers sa définition, via la balise DTD, qui peut être étendue par plusieurs modules. Par exemple, mon dAgence comportait sa propre DTD
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 2.0 plus SVG 1.1 plus WebForms 2//EN" "/interface/xhtml-math-svg-wf2-flat.dtd">
    jusqu'à il y a deux ans. L'URL n'est pas forcément résolue (celles fournies par le W3C ne menaient à rien)
  • Toute entité doit commencer par une esperluette et se terminer par un point-virgule. Exemple : &0x20;
  • Les entités en alias sont par défaut définies à minima pour < , > & et " . Pour le reste, c'est soit du point unicode, soit l'avoir défini en DTD
  • Une balise avec du contenu s'ouvre <balise> et se ferme </balise>
  • Une balise peut imbriquer d'autres balises, mais ne peut être brassée avec une autre balise. la filiation est stricte
  • Une balise sans contenu est autofermante, et s'indique avec un slash final comme suit <balise />
  • les paramètres d'un attribut doivent être bornés par des guillemets <balise attribut1="comme ceci" />

Oui, c'est aussi strict qu'au pensionnat de Chavagnes, mais ça devenait nettement plus simple à parser, voire même à relire : vous n'aviez pas besoin de connaître le rôle d'une balise pour comprendre comment est architecturé un XML. Si vous deviez vous en servir précisément, le dictionnaire du DTD est là pour vous aider. Inutile de dire qu'on était à un autre niveau par rapport aux webmasters du dimanche.

Aussi surprenant que cela puisse paraître, le plus grand zélote du XML fut… Microsoft. En 1999, ils se mirent à mettre du XML partout ! Et il faut reconnaître que dans les applications business, ils y furent pas mauvais…

Si on excepte que dans les XML de Microsoft :

  • La DTD est souvent oubliée
  • L'encodage des caractères est tellement implicite qu'il est souvent oublié, même à la relecture
  • Que pour faire passer la pilule du retour-chariot CRLF propre à l'environnement MS-DOS qui aurait donné deux caractères 0x0D0A, ils ont introduit l'incompréhensible 0xD
Extend and embrance, on était en plein dedans.

Très vite, des formats de documents commencèrent à profiter de la syntaxe XML. On vit rapidement poindre du dessin vectoriel avec le SVG, Microsoft créait des bases de données objets avec des fichiers, et la suite bureautique StarOffice y sauvait des documents de traitements de textes, tableurs, etc… avant de devenir OpenOffice.

Ayant une nouvelle écriture stricte, le W3C a donc proposé à côté du tout neuf mais laxiste HTML4, une syntaxe basée sur le XML, et donc modularisable, extensible et surtout plus stricte sur la manière d'écrire, et sans s'encombrer de la description graphique déléguée à la CSS.

Ainsi vint le XHTML

Et là, on a vite commencé à déchanter.

D'abord, de nombreuses choses étaient prévues de disparaître en XHTML : si on allait vers la version la plus stricte, nous n'aurions plus de <iframe>, bon, ça, on va pas pleurer. Mais les changements allaient aussi dans l'arbre DOM, puisque l'infâme document.write() n'était plus possible en Javascript.
Ça aurait pu être une bonne nouvelle.
Mais en 2008, soit 8 ans après l'introduction de la norme, il était toujours impossible de trouver un éditeur Wysiwyg écrite sans cette instruction maudite. Et je ne vous parle pas des bannières publicitaires.

Autre souci, et non des moindres… Si Microsoft était un utilisateur zélé du XML dans ses solutions business, il fallait aussi reconnaître que son butineur MSIE6, en position archi-dominante, souffrait de comportement totalement aberrants face à du XHTML.

Bref, faites ce que je dis, pas ce que je fais.

XHTML 2 : La vengeance, ou le film de trop

Les industriels du W3C cherchaient à compléter l'avance promise par le XML. Malheureusement, le XHTML2 devenait une réelle usine à gaz, où plus personne n'avançait. Pire que tout, on passait par une absence de compatibilité avec le HTML, donc avec les “navigateurs anciens”. Par exemple, les formulaires passent désormais par des XForms. Côté javascript, le DOM passe à la trappe, remplacé par un modèle XML.

En clair, on était censé repartir de zéro, soit. Mais complètement de zéro : renouveler la logithèque utilisateur et celle des concepteurs. Tous les toolkits JS passent par la même trappe, ainsi que tous les frameworks écrits en Python, PHP ou ASP. Cela aurait demandé un temps d'adaptation non-négligeable, un nettoyage radical des professionnels trop brouillons et une diffusion grand public extrêmement lente.

Autre problème, on est en 2002, et le XHTML2 s'annonçait comme très lourd à interpréter pour les navigateurs embarqués. Les palm pilots et ce qui allait devenir plus tard les smartphones pleuraient déjà leur race à comprendre le wap d'une manière uniforme, là, on allait forcément faire fondre leur autonomie.

WHAT ? WG !

Les développeurs de navigateurs, dont les logiciels sont toujours les principaux utilisateurs de contenu HTML n'étaient doublement pas contents :

  • Construire un site en XHTML2 s'annonçait trop difficile pour un profane
  • Microsoft n'avançait plus, et enterrait le développement de MSIE, étant en position dominante
  • Entre inclure le SVG, les Webforms, le colonage des documents pour le papier, et pourquoi pas introduire des éléments audiovisuels, il y avait un OUvroir WEb POtentiel
  • On n'allait pas attendre 20 années de plus pour évoluer

WAHT-WG avait aussi une volonté d'ouverture : il était plus facile de les joindre, de proposer des idées, de participer à l'écriture de norme que le W3C, ses frais d'inscriptions assez hauts, et surtout son formalisme depuis qu'il est associé à l'ITU, organisme dépendant de l'ONU.

Réconciliation

Devant les avancées du WHAT-WG, mais surtout les mises en œuvres par les navigateurs, le W3C dû reconnaître que le XHTML2 était en plein over-engineering. L'immobilisme était tel que l'échec était évident.

C'est ainsi que le WHAT-WG et le W3C s'associèrent pour écrire ensemble le brouillon du HTML5, mais un brouillon compatible avec le HTML4, hautement évolutif, et dans une idée de progression par l'application rapide.

Seulement depuis 2 ans, les tensions apparurent. À partir du moment où la plupart des développeurs de navigateurs décidèrent de faire disparaître publiquement les numéros de versions des logiciels. Pour le public, connaître quelle version de Chrome ou de Firefox il a sur son PC, finalement on s'en fout, puisque les mises-à-jour étaient devenues automatiques et transparentes.

Qui plus est, depuis le WHAT-WG a parlé de “HTML5”, le domaine était considérablement plus large que le pur langage descriptif. C'est d'ailleurs devenu un acronyme trompeur, puisque le “HTML5” regroupe aussi les avancées en Javascript, dans les API et donc le DOM, dans la CSS, dans les notions de sécurité prophylactiques, dans la couche de transport HTTP, etc…

Rupture

(où l'on apprend que Bernita se fait tromper par Ronaldo avec son chien berger Alemano)

Et le point de non-retour fut d'abandonner le nom même de HTTML5 en Janvier 2011, soulignant que la norme HTML est en évolution continue.

Je vous rappelle que pour la normalisation du HTML/XHTML, on trouve aussi comme membres du W3C des constructeurs de photocopieuses, de suites bureautiques, d'appareils audiovisuels, de bases de données, des bibliothèques, des services d'archivages etc… des gens qui ont un usage tout à fait légitime de ce format de document. Mais le besoin fondamental de ces utilisateurs, c'est que tout document répondant à une norme HTML précise soit encore utilisable dans 20 ans sans dégradation. Non seulement le document, mais aussi ce qui a permis de le générer et ce qui doit le lire.

Le WHAT-WG, lui, est habité par des développeurs de navigateurs, lesquels changent de version au pire tous les 6 mois. Le déploiement de ces nouvelles versions est soit automatique (les mises à jour s'installent toutes seules), soit mécanique (un consommateur hypster change de téléphone portable à chaque conférence Apple).
Dedans, on retrouve deux approches :

  • La “brouillone”, où l'on code immédiatement pour proposer au Group, quitte après à invalider, mais les préfixes constructeurs sont là pour ça. Le moteur webkit (donc les navigateurs Chrome et Safari) a cette approche ultra-expérimentale, hélas au risque d'être incomprise par les too-early-adopters, lesquels confortent sans le vouloir une position digne de Microsoft : extend and embrance (oui oui)
  • La “planifiée”, où l'on propose des idées au Group, dont on attend un consensus pour ensuite commencer à intégrer du code qui mettent en place cette feature. De là, on aura les retours, préciser les manques et donner le ressenti des développeurs. C'est l'approche de la Mozilla Foundation, et c'est ce qui fait croire à un certain “retard” du navigateur Firefox.
L'inconvénient, évidemment, c'est qu'il arrive qu'entre les préfixes constructeurs et l'arrivée à la norme, les gens qui font du site web trop en avance oublient totalement qu'on est parfois encore dans l'expérimentation. Et ça donne de sacrées perles ! (Merci à Jérémie Patonnier pour la crise de rire)

Or, le HTML5 était revenu vers la simplicité, et a totalement abandonné toute déclaration du type DTD.

C'est pas rien… Cela veut surtout dire que le W3C a besoin de savoir quelle syntaxe est valide pour un document HTML précis, donc de connaître à quoi se réfère son générateur, à quelle époque, à quelle version du HTML.
Alors que le WHAT-WG s'en contrefout et considère que toute marche doit être forcée, que le HTML doit être en perpétuelle évolution. Ceci au risque d'abandonner des branches de norme mortes, d'avoir produit à un moment du code inutilisé, de laisser tomber des expérimentations ou que des balises qui n'avaient qu'une utilité restreinte aie d'un coup un fonctionnement impactant dans certains navigateurs. De toutes façons, pour des raisons évidentes de sécurité, on va pas aller surfer avec un navigateur qui a plus de 6 mois sans avoir été mis à jour. C'est aussi mon opinion, mais uniquement pour les navigateurs.

Contrairement à ce que promettait le XHTML, l'écriture laxiste du HTML5 permet de fermer implicitement les balises. À L'ANCIENNE. Et c'est parfois totalement illisible si vous ne connaissez pas exactement l'ordre de priorité des balises, l'ouverture de l'une entraînant parfois, mais pas toujours la fermeture de la précédente.

Regardez le code HTML que vous envoie Google. Je vous jure que ce n'est absolument pas un exemple à suivre. Les raccourcis sont tels qu'il devient vite totalement illisible, à tel point que le terme technique employé est “dégueulasse”. Voici le “mauvais code” selon Google : 

<!-- Not recommended -->
<!DOCTYPE html>
<html>
  <head>
    <title>Spending money, spending bytes</title>
  </head>
  <body>
    <p>Sic.</p>
  </body>
</html>

Et le “bon code” : 

<!-- Recommended -->
<!DOCTYPE html>
<title>Saving money, saving bytes</title>
<p>Qed.

Alors imaginez repasser deux ans après sur du tel code parce que des balises ont changé radicalement de comportement, je vous souhaite bien du courage !

Re-réconcilier ?

Faute de DTD qui indiquait les termes disponibles dans le langage, bien malin sera celui qui peut dire si le document en HTML5 a, par exemple, prévu que la balise <details> se retrouve cachée.

La solution serait de re-signaler dans le doctype quelle version du html “courant” est utilisé. Par exemple, un attribut annonçant la date de conception du logiciel générant le HTML, une valeur purement indicative.

Mais on a le risque de retomber dans l'infernal doctype switching, où un logiciel du type navigateur n'a pas exactement le même comportement. Bref, exactement le genre de bidouillage qui hérisse les boards du W3C et du WHAT-WG.

Et moi...

J'ai intégralement écrit ce billet comme à mon habitude sur mon blog depuis 2004 : en notation XHTML,
à la mano,
directement,
sans éditeur visuel.

Question d'habitude. Et de bonnes pratiques.

J'y pense, et puis j'oublie.