David Madore's WebLog: Validation du HTML5, et énervement

Index of all entries / Index de toutes les entréesXML (RSS 1.0) • Recent comments / Commentaires récents

Entry #1970 [older|newer] / Entrée #1970 [précédente|suivante]:

(samedi)

Validation du HTML5, et énervement

Le HTML a toujours eu une relation de haine-amour avec les validateurs. Les validateurs, ce sont des programmes censés vérifier que le HTML qu'on écrit est (au moins dans une certaine mesure) conforme à la spécification. Par exemple, si on écrit <A HREF="http://example.tld/foobar/">cliquez <B>ici</A></B> le validateur va se plaindre que les balises A et B ne sont pas correctement emboîtées.

Cette relation de haine-amour a eu plusieurs phases.

Il y a eu une phase où le HTML (≤4) était formellement et ostensiblement basé sur une technologie complètement imbitable (i.e., un standard ISO) appelée le SGML : la spécification se présentait comme une extension de ce standard, les les validateurs utilisaient un parseur SGML pour vérifier le HTML. Les navigateurs, eux, fonctionnaient avec un parseur complètement différent, qu'on appelle vulgairement soupe de tags, et qui essaie de se débrouiller du mieux qu'il peut de la merde que les auteurs écrivent. Cette incompréhension fondamentale donnait des choses assez comiques : par exemple si vous faites valider à un validateur HTML4 un truc tel que <P><A HREF=http://example.tld/foobar/>cliquez ici</P> (à mettre au bon endroit à l'intérieur d'un document HTML, bien sûr) il vous dira que c'est correct alors qu'en apparence la balise A n'a pas été refermée — la raison étant qu'à cause des arcanes du SGML (et spécifiquement de la fonctionnalité SHORTTAG), il comprend le code précédent exactement comme <P><A HREF="http:"></A>example.tld/foobar/>cliquez ici</P> ce qui est bizarre mais formellement correct. Naturellement, ce n'est pas du tout ce que comprendront les navigateurs, puisque eux voient une soupe de tags, ils devinent qu'il faut fermer la balise A avant le P et comprennent donc <P><A HREF=http://example.tld/foobar/>cliquez ici</A></P> comme ce que l'auteur voulait (probablement) écrire : on a donc une situation assez paradoxale où le validateur comprend un truc complètement différent de ce qu'on voulait faire, le déclare comme correct, le navigateur, lui, comprend ce qu'on voulait en réparant l'erreur, et du coup on ne remarque pas qu'elle est là.

Puis on a inventé le XML, qui est incroyablement plus simple que le SGML (c'est-à-dire seulement très compliqué), et on s'est mis à tout réinventer à la sauce XML. Le XML a deux niveaux de conformité : un document peut être bien-formé (le niveau minimal : s'il n'est même pas bien-formé, ce n'est pas du XML du tout, et en principe un outil qui cherche à l'analyser a le devoir de le rejeter), et éventuellement valide de surcroît (c'est-à-dire conforme à une certaine déclation sur l'usage des balises, à l'origine il s'agissait de DTD, mais on a inventé différentes autres sortes de mécanismes de validation et du coup le mot valide est assez surchargé). Il y a toutes sortes d'outils pour reconnaître la bien-formitude du XML, et éventuellement la validité selon tel ou tel mécanisme de validité. Pour plein de choses, le XML a eu du succès, mais le HTML a résisté : quasiment personne n'écrit de HTML-sur-XML, ce qu'on appelle XHTML (si le XHTML1 a eu un relatif succès, le 1.1 a été très peu utilisé, et le 2 a été avorté). La raison est sans doute entre autres parce que le XML oblige un navigateur qui détecterait une erreur de non-bien-formitude dans une page XHTML à ne rien afficher du tout sauf le message d'erreur (et de fait, c'est ce que fait Firefox). Mais la raison principale est surtout qu'Internet Explorer ne supporte (supportait ?) pas le XHTML (application/xhtml+xml) : je ne comprends pas vraiment pourquoi, vu qu'il comprend le XML et qu'il comprend le HTML, c'était si difficile de gérer l'un sur l'autre, mais je ne cherche pas à savoir. Comme les deux standards sont de toute façon plus ou moins interopérables (il est possible d'écrire du XHTML valide et de le faire manger à un parseur soupe-de-tags), on peut du moins écrire du XHTML, le valider comme tel, mais le présenter comme du HTML (text/html) ; c'est ce que je faisais moi-même sur ce site Web jusqu'à récemment. L'inconvénient, c'est qu'en faisant ça on s'interdit d'utiliser des technologies comme SVG ou MathML qui ne pouvaient marcher que sur XML.

L'acte III de mon psychodrame concerne l'apparition du HTML5. Le HTML5 propose un nouveau mode de parsage du HTML, qui n'est ni basé sur SGML ni sur XML, ni vraiment le mode soupe-de-tags traditionnel des navigateurs, mais plutôt un nouveau mode soupe-de-tags, décrit de façon complètement formelle, et qui essaie de trouver un compromis entre la robustesse et la reproductibilité ; de plus, ce nouveau parseur rend utilisables certaines des technologies XML (le SVG et le MathML) dans le HTML. Bref, on a maintenant quatre modes de parsage (sur SGML, sur XML, par le nouveau mode HTML5, et l'ancien mode soupe-de-tags, ou plutôt les anciens car il y en a un différent par navigateur). Le HTML5 est aussi prévu pour pouvoir exister sur XML, auquel cas on l'appelle XHTML5, et comme ils ont fait attention à la façon dont le nouveau parseur fonctionne, il est même possible, au prix de quelques efforts, de faire des documents « polyglottes » HTML5/XHTML5, c'est-à-dire qu'ils peuvent se parser aussi bien avec le nouveau parseur HTML5 qu'avec un parseur XML, et si possible avec le même sens (ou des différences négligeables qui n'apparaîtront pas à celui qui lit la page). Les nouvelles pages de ce sites Web sont écrites dans ce style « polyglotte » : je les produis avec des outils XML, donc c'est du XHTML5, mais j'obéis à certaines contraintes qui font qu'ils seront analysés de la même façon par un parseur HTML5 (et, de façon limitée, c'est-à-dire SVG et MathML exclus, par un parseur HTML soupe-de-tags traditionnel). C'est un peu confus à expliquer, mais pas trop difficile au final, et ça marche plutôt bien.

Mais maintenant, comment valider ? Déjà, en principe, je devrais valider chaque page deux fois, une fois avec syntaxe HTML5 et une fois comme XHTML5, puisque mes pages sont censées être les deux à la fois. En fait, côté XML, je n'ai pas trop d'inquiétude, vu que les outils que j'utilise peuvent difficilement produire quelque chose qui n'est pas au moins bien-formé (j'ai eu cependant un cas où un oubli de ma part faisait que des balises ressemblaient à <p xml:lang="en" lang="en" lang="en"> avec une indication redondante d'attribut, ce qui rend le XML non-bien-formé), et si le XHTML5 est bien-formé en tant que XML et également valide comme HTML5, il y a fort à parier qu'il soit du XHTML5 valide (on peut donner des contre-exemples, par exemple en oubliant les bons attributs xmlns, mais il faut un peu le faire exprès). Mais comment vérifier, justement, qu'on a du HTML5 valide ?

En principe, il y a un validateur pour ça. En pratique, il est loin d'être exempt de problèmes. D'abord parce que — et ce n'est pas la faute du navigateur — le standard HTML5 n'arrête pas de bouger. Récemment ils avaient supprimé la balise time. Puis ils l'ont remise, mais avec un modèle différent. C'est un peu agaçant : je comprends qu'ils veuillent être un living standard (ce sont leurs mots), mais enfin, à ce point-là, sept ans après avoir commencé à bosser dessus, ce n'est pas très sérieux. Ensuite, parce que le validateur, je veux en avoir une copie chez moi, pas l'utiliser via un site Web distant (je veux valider mes pages avant de les avoir publiées, et sans forcément avoir l'intention de les publier d'ailleurs), or celui de validator.nu, il est particulièrement lourdingue à faire marcher : en principe le code est disponible, mais c'est une vraie bagarre à compiler, et l'arbre de compilation fait plus de 400Mo. Soyons sérieux ! Est-il normal que ce standard censé rendre le parsage du HTML plus robuste soit aussi monstrueusement compliqué à valider ? Et enfin, parce que ce validateur comporte des erreurs, ou en tout cas des bizarreries, par exemple quand on commence à mélanger le HTML avec SVG et MathML (ce qui était le but, somme toute). Je viens de me rendre compte, par exemple, qu'il n'inclut que les attributs de MathML 2, alors que le standard HTML5 fait (maintenant ?) référence à MathML 3 : du coup, j'ai des pages correctes qui me crachent des bordées d'insultes. Et comme je ne comprends rien à la façon dont fonctionne cette tambouille (en principe c'est juste du RelaxNG+Schematron utilisé derrière un parseur HTML5, mais apparemment les choses sont bien plus compliquées, parce que ça ça n'expliquerait certainement pas d'où sortent les 400Mo), je ne sais pas, par exemple, réparer le truc pour aller chercher les schémas MathML 3[#]. De toute façon, ce validateur a l'air de ne plus être maintenu.

Bref, pour l'instant, la validation HTML5, c'est pas encore trop ça. Alors je pourrais me dire, à quoi bon valider, de toute façon ça n'a pas d'importance, la chose qui importe est d'essayer avec deux ou trois navigateurs et vérifier que la page marche. Mais je n'aime pas cette attitude : d'abord, parce qu'il est parfaitement possible qu'une erreur faite maintenant, surtout sur des standards encore un peu chauds sortis du four, ne se manifeste dans les navigateurs qu'à l'avenir, et de toute façon je n'ai pas beaucoup de choix de navigateurs avec lesquels tester (s'agissant du MathML, comme Safari ne tourne pas sous Linux, j'ai exactement un navigateur utilisable, il se trouve qu'il a de sévères limitations sur précisément un truc que je voulais utiliser et dont le validateur m'aurait permis de vérifier que j'avais écrit les choses correctement dans l'espoir qu'un jour un navigateur les implémente… sauf que le validateur non plus ne connaît pas ces attributs… bref…). Et il y a quand même des fautes que je fais souvent, et qui ne se remarquent pas forcément, comme une faute de frappe dans une balise (comme c'est mon éditeur qui les insère, la même faute se retrouver sur la balise ouvrante et fermante), qu'il est quand même utile qu'un validateur puisse détecter.

[#] Bon, ce n'est pas tout à fait vrai : j'ai trouvé des schémas RelaxNG pour MathML 3, j'ai trouvé comment faire pour que le validateur tente de les charger, mais il me crache l'erreur suivante : Multiple definitions of “image” without “combine” attribute. File: http://s.validator.nu/mathml3/mathml3-content.rnc Line: 94 Col: 1 (de fait, la ligne en question du fichier mathml3/mathml3-content.rnc, qu'on peut trouver dans le fichier mathml3-relaxng.zip téléchargeable par le lien précédent, a pour contenu : image = element image { CommonAtt, DefEncAtt, empty} ; moi je ne sais pas du tout ce que ça veut dire vu que je ne connais pas RelaxNG, mais ce fichier ne contient certainement pas d'erreur vu qu'il est distribué par le W3C, et j'ai tendance à trouver que si le langage n'a pas été prévu pour pouvoir réutiliser tels quels les schémas, c'est vraiment qu'il est complètement pourri).

↑Entry #1970 [older|newer] / ↑Entrée #1970 [précédente|suivante]

Recent entries / Entrées récentesIndex of all entries / Index de toutes les entrées