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).