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.

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 :

• La page peut donc être traitée via toutes les technologies associées (XSL, XPath, ...)
• On peut intégrer dans une page tout dialecte XML (on pensera tout de suite à SVG ou MathML par exemple). Il s'agit de la modularité.

Mauvaises raisons de basculer vers XHTML

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

• Le format de stockage des contenus est très rarement le (X)HTML. Si l'on dispose d'un CMS avec un système de templates, on n'aura sans aucun doute aucun besoin d'utiliser des technologies XML sur les pages envoyées à l'utilisateur final : il suffira de modifier le template ou de créer un processus spécifique d'extraction depuis la base de données.
• Le support pour MathML ou SVG est relativement réduit. Il existe surtout des alternatives en HTML 5 : balises math et svg.

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 :

• C'est une évidence, mais rappelons-le : ne jamais tenter d'expérience « pour se former » sur des sites en production ou avec des impératifs de mise en ligne précis. On le verra, basculer à XHTML n'est pas une mince affaire, et si vous découvrez que les efforts à fournir ne sont pas à la hauteur de ce que cela va vous apporter... vous ferez marche arrière.
• Personne ne peut vous dire de quoi demain sera fait ! Dans un sens comme dans l'autre... Car certes, XHTML est très lourd à utiliser aujourd'hui... mais c'est une question de support des navigateurs ! En faveur du HTML, on peut noter que le W3C a rouvert les travaux sur HTML, suite notemment aux pressions d'acteurs comme le [WhatWG]. Et l'industrie semble maintenant se tourner majoritairement vers HTML5.

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 :

• Transitional
• Frameset
• Strict

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 :

• Les noms d'éléments et d'attributs doivent être en minuscules
• Toutes les balises doivent être fermées, éléments vides ou non. Par exemple si l'on a un <p>, on doit avoir un </p> qui suit. Idem, un saut de ligne est écrit <br />
• Toujours entourer les valeurs d'attributs de guillemets, simples ou doubles
• Les valeurs d'attributs sont systématiquement à préciser (exemple : selected="selected")
• Le contenu des balises script ou style doivent être entourés de CDATA (<![CDATA[ ... ]]>)
• L'attribut name doit être remplacé par des attributs id (sauf pour les éléments de formulaire, cf plus bas)

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 :

• Les différences entre XHTML 1.0 et 1.1 sont détaillées dans l'annexe A de la recommandation XHTML 1.1. En gros, on peut en plus utiliser [Ruby]
• la modularité n'est valable que pour des documents servis comme du XML

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 :

• Insérer une espace devant le slash de fermeture des éléments vide. Par exemple préférer <br /> à <br/>
• Ne pas minimiser les éléments vides dont le modèle de contenu n'est pas EMPTY. En termes clairs : ne pas écrire <p /> au lieu de <p></p>
• Si un style ou un script contient l'un des caractères &, <, >, ]], ou --, il est conseillé de les placer dans des fichiers externes.
• Utiliser les deux attributs lang (pour les vieux navigateurs) et xml:lang (pour les agents lisant du XML), ce dernier ayant la priorité
• En XML, les noms d'ancres dans les URL se réfèrent aux valeurs d'attributs id et non aux valeurs name. Or certains vieux agents n'implémentent pas le support des attributs id comme nom d'ancre. Par précaution, il faut donc spécifier les 2 attributs, par exemple <a id="mon_ancre" name="mon_ancre"> sera accessible directement en ajoutant #mon_ancre dans l'URL.
• En XML, c'est dans le prologue que l'on spécifie le codage. Pour les agents ne connaissant pas XML, il faut continuer de spécifier le codage en balise meta.
• Bien échapper les & dans les URL des références externes : c'est aussi une obligation en HTML mais l'effet sera rédhibitoire sur du XHTML servi avec un content-type XML
• On l'a vu, les éléments et attributs en XHTML doivent être écrits en minuscules - c'est le cas aussi dans les feuilles CSS
• Les balises style doivent recevoir un attribut id et être référencées en tête de document
• L'entité nommée &apos; a été introduite en XHTML 1.0, et ne sera donc pas reconnue par de vieux agents.

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

• Recommandation HTML 4.01
• Recommandation XHTML 1.0
• Recommandation XHTML 1.1
• Recommandation Ruby annotation : un moyen d'annoter des documents XHTML avec des langues non latines.

Documents de référence

• XHTML Media types : un document de synthèse détaillant les types MIME à utiliser pour servir du contenu (x)HTML
• Key words for use in RFCs to Indicate Requirement Levels : RFC 2119. De quoi vérifier ce que SHOULD implique réellement...
• Sending XHTML as text/html Considered Harmful par Ian Hickson : un must-read sur le sujet ! Le postulat de départ est : on a des pages XHTML servies en text/html, tout va bien ! Mais quand on passe au application/xml+xhtml, rien ne va plus ! Bref, ce document est une vraie mine d'or, et contient un tour d'horizon extremement complet des problèmes auxquels il faut faire attention pour un auteur de XHTML aujourd'hui.
• A propos des modes de rendu (standard ou quirks), le document à lire : Activating the Right Layout Mode Using the Doctype Declaration. Quelques explications sur les différents modes de rendu, et un tableau détaillant dans quelles situations les navigateurs majeurs basculent d'un mode à l'autre.

Sites connexes

• Sur OpenWeb on trouvera nombre de très intéressants articles. Notamment : Pourquoi plusieurs variantes de DTD en XHTML ? qui permet de découvrir l'existence des versions Strict, Transitional et Frameset. Sur le sujet qui nous intéresse ici, il y a aussi cet article : passer du HTML au XHTML, qui n'aborde hélas pas les raisons qui peuvent réellement pousser à migrer en XHTML, ni les différents problèmes auxquels on sera confrontés si on s'y plonge - mais c'est quand même une ré-écriture en français, et assez détaillée du chapitre 4 de la recommandation XHTML 1.0
• No to XHTML de Spartanicus, un contributeur régulier de c.i.w.a.html. Ce document liste plusieurs mauvaises raisons de choisir XHTML.
• Le WhatWG, qui propose des évolutions très intéressantes de HTML, en particulier autour des formulaires.
• Le projet FOAF, un exemple de ce que XML peut apporter au Web.
• Chez Blog&Blues, plusieurs articles sur le sujet dont D'ailleur pourriez vous me dire les avantages du XHTML ?

Remerciements

Pour leurs corrections, un très grand merci :

• au compère Vince (uku powered)
• à Alain Buferne pour sa judicieuse question sur l'attribut id (qui a entraine une correction de ce document)
• et surtout à Olivier Miakinen (indispensable contributeur à f.c.i.w.auteurs).

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

Un oubli, une erreur, une suggestion ? Rendez-vous sur le dépôt GitHub !