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.

Servir du XHTML en tant que text/html jugé néfaste

Auteur : Ian Hickson <ian@hixie.ch> (les commentaires sont les bienvenus)

Introduction

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.

Contexte

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.

Résumé

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

Pourquoi il est néfaste d’utiliser text/html avec XHTML

Voici ce qui arrive généralement aux auteurs qui décident d’envoyer du XHTML en tant que text/html :

  1. Un auteur écrit du XHTML en se fondant sur des pratiques uniquement valides pour des agents utilisateurs HTML4 ou « soupe de balises », mais pas pour les agents utilisateurs XHTML, et l’envoie avec le type text/html. (Ces pratiquent sont répertoriées plus bas).
  2. Cet auteur constate que tout fonctionne bien.
  3. Le temps passe.
  4. L’auteur décide d’envoyer le même contenu en tant que application/xhtml+xml parce que, après tout, c’est du XHTML.
  5. L’auteur découvre que son site plante horriblement (voir la liste d’explications ci-dessous).
  6. L’auteur accuse le 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.

Problèmes spécifiques

Les problèmes qui touchent les documents lors du passage de text/html à application/xhtml+xml sont les suivants :

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.

Copier/Coller

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.

Pourquoi tenter d’utiliser du XHTML mais l’envoyer en tant que text/html est néfaste

Ces problèmes n’affecteront pas les auteurs qui valident leurs pages régulièrement, mais les autres rencontreront les problèmes suivants :

Le mythe des 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 :

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

Pourquoi les agents utilisateurs ne peuvent pas traiter le XHTML envoyé avec text/html comme du XML.

Les avantages du XHTML

Quand il est envoyé en tant que application/xhtml+xml, le XHTML a plusieurs avantages :

  1. Le contenu XHTML pourra être mélangé avec du contenu d’autres espaces de nommage bien connus (en particulier MathML). C’est l’avantage principal pour les créateurs de contenu.
  2. Les agents utilisateurs intercepteront immédiatement les erreurs de formation.
  3. Les outils qui interagissent avec du XHTML ont l’assurance de recevoir des documents bien-formés.
  4. Le contenu XHTML peut être parsé avec un analyseur plus simple que pour la soupe de balises, et beaucoup plus simple qu’un parseur SGML.

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.

Conclusion

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

Pour approfondir

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
| &nbsp;, &middot; et &copy;. 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

Annexe A : application/xhtml+xml

Consultez : http://ln.hixie.ch/?start=1036767231&count=1

Annexe B : Auteurs avancés

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.

Annexe C : Remerciements

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.

Annexe D : Notes

[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>&gt;, 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.