Ce document est la traduction de Sending XHTML as text/html Considered Harmful, de Ian Hickson. En cas de divergence ou d’erreur, la version originale anglaise fait référence. D’autre part le document original est régulièrement mis à jour, la traduction peut être en retard sur la version la plus récente.
Date de la traduction : 1er août 2005.
Traducteur : Sébastien Guillon <contact@sebastienguillon.com>
Note : une feuille de styles « Fort contraste » est disponible pour ce document.
Auteur : Ian Hickson <ian@hixie.ch> (les commentaires sont les bienvenus)
text/html
pour du XHTML
text/html
est néfastedocuments XHTML 1.0 compatibles avec HTML
text/html
comme du XML.
Ce document traite de différents problèmes résultants de l’utilisation du type MIME
text/html
avec un contenu XHTML. Je propose que le XHTML servi en tant que
text/html
est brisé et que servir du XHTML en tant que text/xml
est hasardeux, et que par conséquent les auteurs qui destinent leur production au grand public
devraient s’en tenir à HTML 4.01 et que les auteurs souhaitant utiliser du XHTML
devraient servir leurs pages en tant que application/xhtml+xml
.
Ce texte a été écrit en septembre 2002 dans le contexte de cette entrée de mon Web log :
http://ln.hixie.ch/?start=1031465247&count=1
Il a été régulièrement mis à jour depuis, pour corriger certaines erreurs qui ont été révélées dans différentes listes de diffusion et autres forums de discussion. Fin 2004, il est toujours autant d’actualité qu’à l’époque de sa rédaction.
Notez bien que ce document compare le XHTML 1.0 respectant les « Règles de compatibilité HTML »
de l’Annexe C au HTML 4.01, car c’est la seule variante de XHTML pouvant être envoyée
en tant que text/html
.
Si vous utilisez du XHTML, vous devriez le servir avec le type MIME
application/xhtml+xml
.
Dans le cas contraire vous devriez utiliser du HTML4 plutôt que du XHTML.
Faire le contraire, utiliser du XHTML en le servant en tant que text/html
,
entraîne de nombreux problèmes, décrits ci-dessous.
Malheureusement, IE6 ne supporte pas application/xhtml+xml
(en fait, IE n’a aucun support XHTML).
text/html
avec XHTMLVoici ce qui arrive généralement aux auteurs qui décident d’envoyer du XHTML en tant que
text/html
:
text/html
.
(Ces pratiquent sont répertoriées plus bas).application/xhtml+xml
parce que, après tout, c’est du XHTML.Tout les personnes avec qui j’ai parlé ont vécu les étapes 1 à 5 lors de leur passage au type MIME de XHTML. Si l’étape 6 a pu être évitée dans ces cas précis, c’est uniquement parce qu’il s’agissait d’auteurs avancés, à même de comprendre comment réparer leur contenu.
Les problèmes qui touchent les documents lors du passage de text/html
à
application/xhtml+xml
sont les suivants :
Les éléments <script>
et <style>
dans un document XHTML
servi en tant que text/html
doivent être échappés avec des chaînes ridiculement
compliquées.
La raison en est que pour XHTML, les éléments <script>
et <style>
sont des blocs de données du type #PCDATA, et non #CDATA, et par conséquent les balises
de commentaires
<!--
et -->
sont de véritables
balises de commentaires qui ne sont pas ignorées
par l’analyseur XHTML. Échapper un script dans un document XHTML qui pourra
être traité à la fois comme du HTML4 et comme du XHTML nécessite d’utiliser :
<script type="text/javascript"><!--//--><![CDATA[//><!--
...
//--><!]]></script>
Pour incorporer des CSS dans un document XHTML qui pourra être traité à la fois comme du HTML4 et comme du XHTML il faut utiliser :
<style type="text/css"><!--/*--><![CDATA[/*><!--*/
...
/*]]>*/--></style>
Oui, c’est franchement ridicule. Si les documents ne sont pas échappés de cette façon,
le contenu des éléments <script>
et <style>
disparaîtra complètement
quand il sera traité par un analyseur XHTML.
(Tout ceci n’est valable que si vous voulez que vos pages fonctionnent avec les anciens navigateurs et les navigateurs XHTML. Si vous ciblez uniquement des navigateurs XHTML et HTML4, vous pouvez simplifier un peu).
<body>
n’est pas magique
en XHTML, les noms des balises doivent être en minuscules en XHTML). C’est pourquoi l’affichage
des documents est différent lorsqu’ils sont parsés comme du XHTML.
document.write()
ne fonctionneront pas dans un contexte XHTML.
(il faut utiliser des méthodes du noyau DOM).text/html
, les agents utilisateurs actuels sont (au mieux) des agents
utilisateurs HTML4 mais en aucun cas des agents utilisateurs XHTML. Donc si vous leur envoyez
du XHTML vous leur envoyez du contenu dans un langage qui ne leur est pas naturel, et vous vous en
remettez en fait à leur gestion des erreurs. Puisque celle-ci n’est définie dans aucune spécification,
elle peut varier d’un agent utilisateur à l’autre. />
, comme dans
<link />
, ont une sémantique très différente lorsqu’ils sont analysés comme du HTML4.
Donc s’il existait un agent utilisateur vraiment compatible avec HTML4, il serait parfaitement acceptable
d’afficher des >
sur toute la page.Pour plus de détails sur ce point précis référez-vous au troisième point
de la section intitulée Le mythe des documents XHTML 1.0 compatibles avec HTML
.
Le pire problème, et (ce que je soupçonne être) la cause principale de la majorité des pages XHTML véritablement invalides sur la toile, est que les auteurs qui ne connaissent rien à XHTML se sont contentés de copier/coller leur DOCTYPE à partir d’un un autre document. Donc, même si vous écrivez du XHTML valide, par le simple fait d’utiliser du XHTML, vous risquez d’encouragez les auteurs qui n’en savent pas assez pour écrire du XHTML valide à y prétendre malgré tout.
text/html
est néfasteCes problèmes n’affecteront pas les auteurs qui valident leurs pages régulièrement, mais les autres rencontreront les problèmes suivants :
Les documents envoyés en tant que text/html
sont traités
comme de la soupe de balises[1]
par la plupart des agents utilisateurs.
C’est le point essentiel. Si vous envoyez du XHTML en tant que text/html
,
du point de vue des navigateurs, vous leur envoyez tout simplement de la soupe de balises.
Peu importe qu’il soit valide, il sera purement et simplement traité comme s’il s’agissait
de bon vieux HTML 3.2 ou d’une quelconque daube HTML.
Comme la plupart des auteurs ne testent leurs documents que sur un ou deux agents utilisateurs, plutôt que d’utiliser un validateur, cela signifie que les auteurs ne vérifient pas la validité, et par conséquent la majorité des documents actuellement sur le web qui prétendent être du XHTML sont invalides.
Voyez par exemple cette étude : http://www.goer.org/Journal/2003/Apr/index.html#results …mais si vous avez des doutes, libre à vous de menez la vôtre. Pour tout échantillon aléatoire de documents qui semblent prétendre à être du XHTML, une écrasante majorité est invalide.
Donc l’avantage principal d’utiliser du XHTML, le fait que les erreurs sont détectées tôt parce
qu’il
doit être valide, est perdu quand le document est envoyé en tant que text/html
.
(oui, j’ai bien dit la plupart des auteurs. Si vous êtes un des rares auteurs qui comprennent
comment éviter les problèmes présentés dans ce document et qui valident effectivement leur code,
alors ce document ne vous concerne probablement pas — consultez l’Annexe B).
text/html
à application/xhtml+xml
, vous vous retrouverez très probablement avec un nombre
considérable d’erreurs XML, avec pour conséquence que vos utilisateurs
ne pourront pas lire votre contenu. (voir ci-dessus : la plupart de ces documents ne sont pas valides.)text/html
sur son disque dur et l’ouvre ensuite en local,
déclenchant ainsi le mécanisme de reniflage de type de contenu, étant donné que les systèmes de fichiers n’incluent
généralement pas d’information sur le type de fichier, le document pourrait être ouvert en tant que XML,
avec comme résultat possible des erreurs de validation, des différences de parsing, ou des différences
d’affichage au niveau des styles. (les mêmes différences que lorsque vous envoyez le fichier un type MIME XML)documents XHTML 1.0 compatibles avec HTML
La RFC2854 fait référence à un profile
d’utilisation du XHTML compatible avec HTML 4.01
. Ce profile est un mythe.
Les documents qui suivent les règles de l’Annexe C ne sont pas des documents HTML 4.01 valides.
Ils sont juste assez semblables pour qu’un analyseur de soupe de balises soit
capable de les traiter de la même façon que la majorité du reste des pages sur le web.
Les exemples les plus simples sont les suivants :
La syntaxe />
pour les balises vides a en fait un sens totalement différent en HTML4.
(il s’agit de la forme minimisée SHORTTAG connue sous l’appellation NET, si mon souvenir est exact).
En particulier le XHTML
<p> Hello <br /> World </p>
...est exactement équivalent, lorsqu’il est interprété en HTML4 à :
<p> Hello <br>> World </p>
...et devrait en fait être affiché comme suit :
Hello
> World
Le contenu des éléments script et style ne peut pas être caché aux navigateurs les plus anciens. Ce code XHTML :
<style type="text/css">
<-- /* hide from old browsers */
p { color: red; }
-->
</style>
...est exactement équivalent à ce code HTML4 :
<style type="text/css">
</style>
...parce que les commentaires ne sont pas ignorés dans les blocs <style>
en XHTML.
xmlns
est invalide en HTML4.Utiliser du XHTML et l’envoyer en tant que text/html
revient en fait,
du point de vue de HTML4, à écrire de la soupe de balises (reportez-vous à la section
Pourquoi les agents utilisateurs ne peuvent pas traiter le XHTML envoyé
avec text/html
comme du XML. ci-dessous).
Note : Ce point est traité dans XHTML-1.0/6232 du HTMLWG :
http://hades.mn.aptest.com/cgi-bin/voyager-issues/XHTML-1.0?id=6232;expression=appendix%20c;user=guest
text/html
comme du XML.text/html
sont traités comme de la soupe de balises
par la plupart des agents utilisateurs.
Cela signifie que les auteurs ne valident pas leurs pages,
et par conséquent la majorité des documents XHTML actuellement sur le web sont invalides.
Un agent utilisateur XML conforme ne pourra donc pas afficher autant de documents
qu’un agent utilisateur actuel, et n’aura donc jamais une part de marché suffisante.
text/html
.
C’est pourquoi les agents utilisateurs ne pourront jamais traiter des documents
text/html
en mode XML, même s’ils ne s’inquiétaient pas de leur propre viabilité
(voir le premier point de cette section).
<?xml
parce que :
<?xml
... ?>
est optionnel
et il est recommandé de ne pas l’inclure
parce qu’il fait passer IE6 en mode quirks.Vous ne pouvez pas vous baser sur la chaîne <html xmlns
parce qu’elle peut être là mais cachée dans un commentaire (il faudrait
utiliser un analyseur XML complet pour passer outre les commentaires,
les instructions de traitement, les sous-ensembles internes, etc.)
Par exemple, en quel langage ce document text/html
est-il écrit ?
<?xml pas du tout?> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN" [ <!-- SYSTEM "pas du XHTML" --> ]> <!-- -- --> Ceci est un commentaire. Ce document n’est pas du XHTML. <html xmlns="http://www.w3.org/1999/xhtml"/> Voilà, j’ai terminé. --> <html> <title> Il faut toujours un titre en HTML4 ! </title> <p> Ceci est un document HTML4 valide. </html>
Quand il est envoyé en tant que application/xhtml+xml, le XHTML a plusieurs avantages :
Cependant aucun de ces points ne s’applique quand un document XHTML est envoyé
en tant que text/html
et puisque les auteurs pensent que leurs pages
doivent pouvoir être vues avec le navigateur le plus populaire,
qui ne supporte pas application/xhtml+xml
, il n’y a
finalement aucun intérêt à utiliser du XHTML pour le moment.
Il y a peu d’avantages à utiliser du XHTML si vous envoyez le contenu
en tant que text/html
, mais de nombreux inconvénients.
De plus, actuellement, la majorité (plus de 90% d’après la plupart
des statistiques) du marché des agents utilisateurs est incapable d’afficher
correctement le XHTML véritable envoyé en tant que text/xml
(ou autre type MIME XML). Allez par exemple avec Internet Explorer sur :
http://www.mozillaquestquest.com/
Seul Mozilla, les navigateurs basés sur Mozilla comme Netscape 6 et 7, les versions récentes d’Opera, et Safari sont capables d’afficher correctement ce site. (IE6 affiche une arborescence DOM !)
Les auteurs qui se refusent à utiliser un des types MIME XML devraient continuer à écrire du HTML 4.01 valide pour le moment. Lorsque les agents utilisateurs supportant le XML et le XHTML envoyé avec un des types MIME XML seront plus répandus, les auteurs pourront envisager l’apprentissage et l’utilisation de XHTML.
(Les auteurs avancés devraient également consulter l’Annexe B.)
J’ai écrit un autre document sur un sujet similaire
à propos des gens qui veulent que les agents utilisateurs traitent les
documents XHTML envoyés en tant que text/html
comme du XML
et non comme de la soupe de balises.
http://www.damowmow.com/playground/xhtml-in-uas.xhtml
Henri Sivonen a écrit un document similaire où il pose la question de l’utilité de XHTML :
http://www.hut.fi/u/hsivonen/xhtml-the-point
Il y a également de nombreuses listes de diffusion sur le sujet, par exemple www-talk.
Le post suivant récapitule certains des problèmes liés à l’utilisation de
text/html
pour une page XHTML contenant des extensions XML :
http://lists.w3.org/Archives/Public/www-talk/2001MayJun/0046.html
Certaines personnes ont rencontré les problèmes cités dans ce document, comme :
http://flrant.com/index.php?id=P21
Il y a aussi quelques arguments intéressants dans d’autres posts, par exemple :
| > Mais est-ce que Mozilla fait appel à son analyseur XML sur | http://www.w3.org/ ? | Non. Si c’était le cas, il afficherait la page sans développer les | références d’entités de caractères, puisque Mozilla n’est pas un parser | validant et donc passe sur l’analyse de la DTD et donc ne reconnaît pas | , · et ©. Sans parler du fait qu’il ignorerait | la partie de la feuille de styles dédiée au média print, qui utilise | des noms d’éléments en majuscules et qui ne correspondraient donc à aucun des | des éléments en minuscules (ligne 118 de la première feuille de styles), et | il utiliserait une couleur de fond inattendue pour la page parce que la | feuille de styles attribue la couleur de fond pour <body> et non pour | <html>, ce qui résultera en XHTML à un affichage différent de | l’équivalent HTML4 (même feuille de styles, ligne 5). -- http://lists.w3.org/Archives/Public/www-talk/2001MayJun/0004.html
Ou cette réponse, vers la fin de la discussion :
| Je n’ai toujours pas trouvé de bonne raison d’écrire des sites web en XHTML | _pour le moment_, étant donné que la majorité des navigateurs web ne | calculent pas le XHTML. LA seule raison qui m’ait été donnée (par Dan | Connolly [1]) est que ça rend plus facile la gestion de contenu avec des | outils XML... mais il serait tout aussi facile de convertir le XML en soupe | de balises ou en HTML avant de le publier, donc je ne suis pas sûr de | comprendre cet argument. Et combien même, avoir un contenu XML pour la gestion | de contenu est une chose, mais pourquoi faut-il obliger une minorité de | navigateurs à traiter le document comme du XML et pas comme de la soupe de | balises ? Que gagne-t-on à le faire ? Et _même_ si la personne | qui a la maîtrise du contenu utilise des outils XML, etc. elle a | certainement également la maîtrise du site web, alors pourquoi ne pas | faire la bidouille de type de contenu côté serveur au lieu de faire campagne | pour que les auteurs d’agents utilisateurs affectent leurs ressources déjà | limitées à développer un reniflage de type de contenu ? | | [1] http://lists.w3.org/Archives/Public/www-talk/2001MayJun/0031.html -- http://lists.w3.org/Archives/Public/www-talk/2001JulAug/0005.html
application/xhtml+xml
Consultez : http://ln.hixie.ch/?start=1036767231&count=1
Certains auteurs avancés savent envoyer du XHTML
en tant que application/xhtml+xml
aux agents utilisateurs
qui l’acceptent et en text/html
aux anciens agents utilisateurs.
En admettant que vous utilisez du XHTML 1.0 respectant les règles de
l’Annexe C (ou si vous avez vérifié par un moyen quelconque la compatibilité de
votre XHTML 1.0 avec les analyseurs de soupe de balises),
alors tout va bien. Ce que je dis dans ce document, c’est qu’envoyer
du XHTML uniquement avec text/html
est néfaste.
Note : envoyer du XHTML 1.1 en tant que text/html
n’est
jamais acceptable. Aucune spécification ne l’autorise. Envoyer
du XHTML 2.0 dans un contexte de production (hors test) de quelque
façon qu ce soit, n’est jamais aceptable non plus, puisque
la spécification n’a pas encore atteint le statut de recommandation candidate.
Notez également que je préconise personnellement que même les auteurs avancés
n’envoient pas de XHTML en tant que text/html
, parce que de nombreux auteurs
copient/collent le balisage d’autres sites et peuvent ainsi copier du code XHTML
valide mais l’envoyer comme du HTML4.
Merci à Nick Boalch pour l’extrait. Merci à Dan Connolly pour son extrême souci du détail qui a amélioré la qualité de ce document. Merci à Ted Shaneyfelt et aux nombreux autres qui ont apporté leurs suggestions d’améliorations pour ce texte.
[1]
L’expression « traité comme de la soupe de balises »
renvoie au fait que les agents utilisateurs ont
traditionnellement une gestion des erreurs très laxiste
et ne supportent aucune des fonctionalités avancées de SGML.
Par exemple, les navigateurs traitent la chaîne
<br/>
comme <br>
au lieu de
<br>>
, alors que
selon SGML c’est la seconde forme qui devrait être affichée.
De même, les agents utilisateurs existants n’ont aucun problème à accepter
un contenu du genre : <b> foo <i> bar </b> baz </i>
alors que d’après la spécification HTML4 ça n’a aucun sens.