Informatique
HTML ou XHTML ?

Ce document a été écrit au cours de l'année 2005, alors que beaucoup de concepteurs fonçaient tête baissée vers XHTML, en oubliant un peu vite à mon goût le HTML Strict. Il m'avait paru important de souligner les avantages mais aussi les inconvénients de cette bascule vers XHTML... Car ça n'est pas anodin ! Je me suis donc lancé dans la rédaction de ce document avec la volonté de construire une synthèse claire et complète !

Depuis bien sûr, le paysage a bien évolué ! Le HTML 5 qui était alors défendu par le WhatWG a été intégré dans les technologies du W3C, les navigateurs ont commencé à bien l'implémenter... La question ne se pose donc plus du tout de la même manière bien sûr ! Cependant, il reste utile de connaitre ces quelques subtilités.

Table des matières + X

Les avantages de XHTML

HTML est basé sur SGML. Ce dernier étant assez lourd et compliqué, le W3C s'est orienté vers XML, et a donc adapté HTML : ainsi est né XHTML.

Les avantages de XHTML tournent donc tous autour du fait qu'il s'agit de XML. Ainsi :


Mauvaises raisons de basculer vers XHTML

Les avantages exposés plus haut sont à tempérer :

Ceci étant dit... Il circule beaucoup de fausses idées sur XHTML. En voici quelques unes, et les explications associées.

Je veux développer en suivant les standards du W3C, et leur standard c'est XHTML !

Comme dit plus haut, c'est d'abord sur HTML que le W3C a publié des recommandations. Avec leurs recommandations, XHTML tout comme HTML sont donc des standards !

XHTML est le futur, il est nécessaire que je l'apprenne

2 choses :

Je veux profiter à fond de CSS, supprimer tous les FONT, et XHTML est la solution !

Très important : on a finit par l'oublier, mais HTML n'est pas synonyme de "bouillie-à-la-mode-des-années-90", bref de multiples tableaux imbriqués, de balises font qui n'en finissent pas, etc.

En effet, HTML comme XHTML proposent plusieurs versions :

Vous retrouverez ces définitions dans les recommandations XHTML comme dans celles pour HTML. Un article d'OpenWeb, [Pourquoi plusieurs variantes de DTD en XHTML ?] (qui traite d'ailleurs autant de HTML que de XHTML) détaille aussi ces 3 différentes versions.

Si l'on choisit une version Strict, on est dans une véritable séparation fond / forme, et donc plus du tout dans l'horreur que l'on évoquait plus haut ! Sur ce point, HTML et XHTML sont totalement comparables.

Dans tous les cas, précisons que passer de HTML Strict à XHTML Strict servi en application/xml+xhtml est assez simple. Dans un premier temps et pour suivre une progression logique, vous avez donc bien plus intérêt à vous exercer à créer des pages en Strict et à utiliser au mieux CSS.

XHTML est plus strict que HTML

En HTML, des balises peuvent ne pas être fermées (c'est d'ailleurs très accomodant pour les pages contenant beaucoup de balisage de tableaux), et seul l'élément TITLE et le DOCTYPE sont absolument indispensables. Ainsi, cette page au balisage très étrange venu d'ailleurs est tout à fait valide...

Cependant... Ce genre d'exemples sont plus des cas d'école. Dans la pratique, un concepteur Web doit faire attention à tellement de problématiques (validité, séparation fond/forme, accessibilité, temps de chargement, ...) que l'on peut considérer comme négligeable cet avantage. En effet, pour produire un site respectueux des recommandations W3C, il faut le vouloir... Et dans ce cas on ne produira pas de pages sans BODY ou HEAD !

A noter qu'une page XHTML invalide et lue comme du XML ne sera pas affichée (on y reviendra plus bas) : un peu trop strict pour le coup :).

XHTML est plus simple que HTML

Même en laissant de côté toutes les complications que l'on rencontre en XHTML pour conserver la compatibilité avec les vieux agents (et il y en a foison, et il faut pourtant impérativement les respecter aujourd'hui !), c'est un argument qui paraît impossible à tenir.

Par exemple, voyez les attributs qui doivent avoir une valeur : selected="selected" (voir la rec XHTML chapitre 4.5). Ou encore la nécessité d'entourer les contenus de balises script ou style par des blocs CDATA (voir la rec XHTML chapitre 4.8)

Bref, même si cela ne complique quand même pas dans des proportions délirantes la tâche des concepteurs, il reste que XHTML est légèrement plus lourd que HTML dans sa syntaxe.

Et encore une fois, c'est sans compter toutes les contraintes de compatibilité (nous les détaillerons plus loin) à impérativement respecter !

Mon site doit pouvoir être lu parfaitement sur mobile !

A la rédaction initiale de cette page en 2005, les smartphone étaient tout récents... On avait plutôt des PDA ou des feature phone en iMode (pages écrites en cHTML) ou WAP (pages en WML ou XHTML Basic).

Les navigateurs mobiles utilisés aujourd'hui, bien entendu, orientent leur compatibilité première vers le parc de sites installés... et donc vers HTML !


Différences entre HTML et XHTML

Généralités

De par la nature différente de HTML et XHTML, il y a plusieurs nouveautés à respecter en XHTML :

Ces différences sont bien détaillées dans le chapitre 4 de la recommandation XHTML 1.0, et aussi dans un article d'OpenWeb : [Passer du HTML au XHTML].

Attribut id

L'attribut name disparait comme "fragment identifier" et est remplacé par id : c'est cet attribut en particulier que l'on utilisera comme ancre (http://serveur/chemin/document#ancre).
Plus de détails sur le sujet dans le chapitre 4.10 de la recommandation et dans le chapitre 8 de son annexe C.

Les éléments de formulaire (élément input) conservent bien l'attribut name.
A ce sujet, consulter cette discussion sur le groupe Usenet fr.comp.infosystemes.www.auteurs : Id, name et radio.

Code XHTML invalide

Une page XHTML servie en tant que telle (content-type application/xml+xhtml) et dont le code est invalide, ne sera pas affichée par un navigateur conforme. A la place, c'est une erreur du parseur XML qui sera affichée.


Contraintes de compatibilité

Type MIME

Le document [XHTML media types] précise qu'un document XHTML 1.1 doit (« SHOULD ») être servi en utilisant le content-type "application/xml+xhtml", et pas (« SHOULD NOT ») avec le type "text/html". Les termes utilisés pour indiquer ces contraintes sont précisément définis dans la [RFC 2119] :

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

Sachant qu'aucune règle de compatibilité n'existe en XHTML 1.1, il faudra qu'un tel document soit lu par le parseur XML des agents utilisateurs. Et on comprend donc cette contrainte...

Maintenant, arrivons au plus drole... Internet Explorer (toutes versions jusqu'à la v8 incluse) ne gère pas ce type MIME... Cf CanIUse.com. Et sur Safari iOS le support aussi est récent (depuis la v7.1). Si vous êtes confrontés à ces navigateurs, alors cela condamne pour vous l'usage de XHTML 1.1.

Notons au passage que :

XHTML 1.0 Annexe C

Vu ce qui a été dit juste au-dessus, on se rabat donc sur XHTML 1.0, servi en text/html. Or de nombreux navigateurs ne connaissent pas XHTML, et liront un tel document comme du HTML invalide. Afin de ménager ces vieux agents utilisateur, il faut suivre les différents points exposés dans l'annexe C de la recommandation XHTML 1.0.

Voici les points les plus importants contenus dans cette annexe :

En fait, on le voit, on a tout intérêt à développer son XHTML d'abord en le servant en tant que XML. Ensuite, on pourra l'adapter pour qu'il soit correctement lu en text/html par d'anciens agents.

L'excellent document [Sending XHTML as text/html Considered Harmful] (un must-read, vraiment !) a d'ailleurs été écris au départ en pensant aux problèmes rencontrés en passant un document XHTML du text/html au application/xhtml+xml...

Internet Explorer et prologue XML

Le prologue XML, c'est ça :

<?xml version="1.0" encoding="UTF-8"?>

Si ce prologue est présent, alors votre document sera affiché par Internet Explorer, jusqu'à la version 6 incluse, Mac ou Windows, dans son [mode de rendu Quirks]... Et cela posera donc beaucoup de problèmes aux CSS !

Notons que l'absence de prologue rendra difficile l'utilisation d'outils XML sur ces pages (problèmes codage par exemple).


Conclusion

A l'époque de la rédaction initiale de ce document, le très gros argument contre XHTML était l'impossibilité de servir les pages avec le type MIME adapté.

A ce jour (octobre 2014), il est possible de faire du "vrai" XHTML en utilisant bien application/xml+xhtml. Cependant, les apports sont très relatifs, et surtout vous aurez l'absolue nécessité de ne servir QUE des pages valides à vos utilisateurs, car à la moindre erreur leur sera présenté un message technique abscon. Et puis, la syntaxe XHTML est tout de même plus lourde que celle de HTML, sans compter les nouveautés HTML 5 (autour des formulaires en particulier, à comparer avec XHTML Forms).


Liens

Recommandations W3C

Documents de référence

Sites connexes


Remerciements

Pour leurs corrections, un très grand merci :


Création le 19/07/2005
Dernière mise à jour le 16/10/2014

Un oubli, une erreur, une suggestion ? N'hésitez pas à me contacter sur pgoiffon -at- free.fr