Le langage à balise XHTML est promu comme le nouveau messie du web, capable de venir à bout des lacunes de HTML, de s'intégrer avec tous les standards en cours, et de mieux préparer l'avenir.
Tout cela est bien joli mais en fin de compte, pour de nombreux développeurs Web, la différence entre HTML et XHTML tiens en quelques habitudes à prendre:
- coller un DOCTYPE en haut du fichier,
- fermer toutes les balises,
- pour les balises simples, les fermer "de l'intérieur" (comme <br /> ou <img />),
- toutes les balises en minuscules,
- les arguments entre guillemets,

...et voilà, à peu de chose près, la vision de nombreux développeurs de ce nouveau héros du Web : un HTML en plus contraignant. En définitive, on ne voit en général pas vraiment l'intérêt de passer à XHTML, puisque HTML marche toujours aussi bien et qu'il laisse plus de liberté.

Pire encore, la toute dernière version de XHTML, le 2.0, rend de nombreuses balises chéries des webmasters non seulement obsolètes (elles les sont depuis HTML 4.01...) mais surtout interdites : la plupart des balises de présentation pure (<i>, <br>...) ne sont pas présentes dans la spécification, et il est conseillé de se reporter sur les CSS pour la mise en page. XHTML 2.0 casse complètement l'esprit "compatible" qui régnait entre HTML et XHTML 1.x.

Certes, XHTML 1.0 date de l'an 2000 est n'est toujours pas appliqué massivement, et d'aucuns pense que XHTML 2.0 ne parviendra pas à s'imposer, mais une question reste : pourquoi XHTML ?

Rigueur, portabilité et extensibilité
Bloqué entre le HTML vieillissant et le XML trop avancé/différent pour remplacer du jour au lendemain HTML, le W3C a proposé une solution intermédiaire par laquelle construire l'adoption de XML comme langage principal du Web. XHTML 1.0 mettait donc HTML à la sauce XML, et le langage vieillissant gagnait une seconde jeunesse.

Rigueur. Le Web de 2004 n'est plus celui de 1994 : une page n'est plus lue par un être humain, elle peut aussi être parcourue par un robot (à commencer par ceux de Google, Yahoo! ou MSN). Pour faciliter leur travail d'indexation et d'analyse, il est nécessaire de leur proposer des documents qu'ils puissent reconnaître facilement. XML est le parfait exemple d'un format conçu pour être à la fois lisible par l'oeil humain et par la machine, mais se cantonne encore aujourd'hui aux services Web ou à l'échange de données entre machines. XHTML tente d'offrir cette rigueur aux pages Web elle-même, pour à terme rendre le Web plus facile à traiter et donc plus accessible à tous.

Portabilité. Le Web de 2004 n'est vraiment plus celui de 1994 : on peut maintenant le parcourir depuis son ordinateur, mais aussi son téléphone portable, son organiseur électronique, sa voiture, sa télévision, son réfrigérateur, et combien d'autres choses dans les années à venir. Mais tous ces supports n'ont pas les mêmes capacités - mémoire, nombre de couleurs, capacité de traitement. Les supports les plus portables seront certainement les plus utilisés à l'avenir, mais aussi ceux avec le moins de capacité mémoire pour se permettre d'inclure un analyseur de "mauvais HTML" (on parle alors de tag soup, soupe de balise) et devront se limiter à un analyseur plus compact et plus strict. Pour s'afficher sur les supports à venir et assurer sa pérennité, un site devra adopter la syntaxe stricte de XHTML, au risque de ne plus être lisible que devant un ordinateur...

Extensibilité. Le "x" de XHTML signifie eXtensible : XHTML est donc une version extensible de HTML.... mais dans la pratique courante, force est de constater que l'on se sert de XHTML comme de HTML : tel quel, sans chercher à l'étendre. Cette extensibilité est pourtant une grande force de XHTML, comme nous allons le voir dans cet article.

L'extensibilité de XHTML
XHTML 1.0 est donc une "reformulation de HTML en XML" : compatible avec les anciens navigateurs, mais disposant des apports modernes de XML. Notamment, XML apporte la technique des espaces de nommage (namespaces), qui permettent de combiner plusieurs DTD (Document Type Definition) au sein d'un seul document.

En pratique, cela modifie grandement les capacités d'une page. Une page HTML ne pouvait afficher que du HTML, et si l'on voulait utiliser un autre langage de balises pour une utilisation spécifique, il fallait le faire sur une page à part : MathML, XSLT, SVG, autant de technologies que l'on devait mettre à part, et donc en définitive peu utilisées.

Avec les espaces de nommage, XHTML permet de combiner ces différents langages en un seul document, pour peu que ces langages disposent d'une sémantique clairement définie par une DTD, celle-ci étant spécifiée en en-tête du document. Cela permet ainsi l'utilisation combinée de toute norme utile au sein d'un seul document - pour peu que le navigateur/lecteur soit capable de les traiter.

Voici par exemple les premières lignes du weblog de Jacques Distler, un des pionniers en matière d'applications des extensions XHTML (en l'occurrence, XHTML avec MathML) :

<?xml version='1.0' encoding='iso-8859-1'?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 2.0//EN" "http://www.w3.org/Math/DTD/mathml2/xhtml-math11-f.dtd" >
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
  <head>
...

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
    <title>A Math Example</title>
  </head>
  <body>
    <math xmlns="http://www.w3.org/1998/Math/MathML" mode="display">
      <mo>∫</mo>
      <msup><mi>e</mi> <mi>x</mi></msup>
      <mi>dx</mi><mo>=</mo>
      <msup><mi>e</mi> <mi>x</mi></msup>
    </math>
  </body>
</html>

Customisation et modularisation
Il ne faut pas voir le terme "customisation de HTML" de la même manière qu'à la grande époque de la guerre des navigateurs, où les deux plus grands faisaient reconnaître de nouvelles balises en espérant ainsi rallier les développeurs à leur outil. Cette époque est terminée, et l'évolution de HTML est désormais régulée.

Par customisation, on n'entend donc pas "amélioration sauvage et personnelle" mais plutôt "capacité à piocher les fonctionnalités voulues" : en utilisant les DTD nécessaires au document, on "retravaille" XHTML a sa manière (en créant ses propres DTD par exemple), sans pour autant devenir incompatible étant donné que le navigateur a accès aux DTD, donc aux définitions même des balises.

La réelle avancée tient dans la modularisation de XHTML. Simplement, le W3C a pris le parti de décomposer littéralement la spécification XHTML en de nombreux modules, libre ensuite aux développeurs d'appeler ceux dont ils ont besoin, en partant de la DTD de base, XHTML-Basic. Vingt-huit modules sont ainsi disponibles : texte, liens, listes, formulaire, calques, scripts, style...

L'intérêt : permettre de cibler les supports n'intégrant qu'une partie des modules (ou inversement, de ne créer des supports ne reconnaissant qu'une partie des modules), tout en respectant la norme HTML. Cela réduit donc grandement les problèmes d'implémentation et de développement pour le support.

Forum

Réagissez dans les forums de JDN Développeurs

XHTML-Basic est ainsi une première application de cette modularisation : la spécification n'intègre qu'une partie des modules, et est donc sensée pouvoir fonctionner sur toutes les plate-formes, tous les lecteurs, tous les navigateurs - notablement les téléphones portables : XHTML-Basic rejette de nombreuses balises impropres à ce support. A terme, elle devrait remplacer WML et C-HTML.
XHTML Mobile Profile est a de son coté été créée par Nokia a partir de XHTML-Basic, avec quelques modules en plus.

La modularisation permet donc de combiner des modules courants/obligatoires, des modules publics et de modules privés, pour arriver à un document lisible par tout navigateurs capable de traiter XHTML.