Pourquoi choisir XHTML, par Steven Pemberton du W3C

Molly E. Holzschlag a réalisé une interview de Steven Pemberton, chairman des groupes de travail HTML et formulaires au W3C à propos d’XHTML, et plus précisément des raisons pour lesquelles il faut choisir XHTML. Cette traduction en français devrait éclairer pas mal de zones d’ombre à l’heure où HTML5 a clairement le vent en poupe.

Premièrement, quelques rappels. je donne régulièrement des conférences dans lesquelles j’explique pourquoi le livre est condamné. Je pense que le livre est condamné pour les mêmes raisons que j’ai pensé que les écrans cathodiques ou les appareils photos argentiques l’étaient. Les personnes présentes à ces conférences font généralement l’erreur de penser que, puisque je pense que le livre est condamné, je milite pour sa disparition, et viennent par là me chercher des poux dans la tête. En réalité, j’aime les livres. J’en possède même des milliers… mais ça ne m’empêche pas de penser qu’ils sont amenés à disparaître.

De la même manière, beaucoup de gens pensent que, puisque je suis la voix derrière le XHTML, je pense nécessairement que le XML est parfait, et qu’il va résoudre le problème de la faim dans le monde.

Je ne le pense pas, même si…

On m’a demandé de créer XHTML et je l’ai fait.
XML n’est pas parfait. En fait, je pense que ses concepteurs étaient trop focalisés sur l’impression, et n’ont pas anticipé correctement toutes les applications qui pouvaient en être faites. Comme le dit si bien Tim Bray, Vous savez, les mecs qui ont inventé XML étaient une poignée de fondus des technologies de publication, et nous pensions réellement créer le format de documents du futur. On n’avait aucune idée du fait que les gens l’utiliseraient pour créer des flux de syndication ou pour donner des ordres d’achats.
J’ai à plusieurs reprises tenté de faire corriger quelques unes des pires erreurs de XML, et pas toujours avec succès.
XML existe, il existe un paquet d’outils permettant sa manipulation, il est interopérable, et il résout une bonne partie des problèmes de l’humanité.

Le parsing

Ah, le parsing. Tout le monde ou presque a grandi avec la permissivité du HTML et a fini par s’y habituer. HTML a été conçu pour être user friendly. J’ai coutume de l’appeler le balisage de grand-mère. Il reste pourtant un problème sous-jacent qu’on a un peu trop tendance à cacher sous le tapis : ce contrat non écrit que le développeur passe avec son navigateur. Vous créez le document, le navigateur l’interprète. Maintenant, si votre syntaxe n’est pas correcte, le navigateur va tenter de deviner ce que vous avez voulu faire et va l’interpréter quand même. Mais vous n’avez pas rempli votre partie du contrat.

Si la page ne s’affiche pas correctement, c’est de votre faute, même si vous ne le savez pas forcément (en particulier si vous êtes Madame Michu). Comme votre navigateur va tout de même tenter de l’afficher comme il peut, vous allez devoir tester votre code sur tous les modèles du marché, puisque chacun vous corrigera à sa manière. En d’autres mots, l’interopérabilité devient la responsabilité de l’utilisateur (c’est d’ailleurs la même chose pour le langage C, mais pour des raisons à la fois semblables et différentes).

Maintenant, si HTML n’avait pas eu un parseur aussi laxiste, il n’y aurait pas une seule page au monde qui ne serait pas syntaxiquement parfaite, parce que tout le monde teste visuellement ses pages et se fout du reste :

J’écris ma page.
Je regarde ce que ça donne dans mon navigateur.
Ça compile ? On se casse !

Et on réessaie jusqu’à ce que ça ait l’air de fonctionner. Si cette itération incluait également la validation de la syntaxe HTML, personne ne se plaindrait. Personne ne râle parce qu’un compilateur remonte les erreurs de syntaxe (ça c’est à voir, ndt), mais sur le web, personne ne vous dit que vous avez corrigé vos erreurs.

En fait, la chose a un jour été essayée avec les langages de programmation. PL/I avait un parseur très laxiste, avec pour résultat que la majorité des programmes ne faisaient pas du tout ce que leurs concepteurs souhaitaient qu’ils fassent. Par chance, les autres langages de programmation n’ont pas suivi cette voie.

Pour un langage de programmation, le laxisme est une catastrophe. Pour une page HTML, c’est juste un désagrément, même si, avec Ajax, les choses pourraient s’améliorer si seulement vous saviez vraiment que le DOM était ce que vous pensiez qu’il est.

Les concepteur d’XML ont dit ne refaisons pas deux fois la même erreur, et si tout le monde avait été d’accord, les choses auraient marché. Mais sur le web, dès qu’un des joueurs décide de ne pas tenir sa promesse, ça se termine en course à l’armement, et tout le monde finit par redevenir laxiste. On a perdu une bonne occasion.

Cela dit, connaître les erreurs de syntaxe est toujours une bonne chose, même si le navigateur les corrige. Et je pense qu’une gestion des ferme des erreurs ne doit pas être aussi draconienne que certaines personnes aimerait que nous la pensions.

Je suis donc un supporter modéré du parsing stricte, tout comme je le suis avec les langages de programmation. Je veux que mon navigateur m’indique quand mes pages sont incorrectes, tout en corrigeant les erreurs des autres sur lesquelles je n’ai aucun contrôle de telle sorte que je puisse toujours les voir.

Il y a autre chose. Le monde ne se compose pas uniquement de navigateurs. Le parsing du XML est vraiment chose facile, tout comme il est simple de créer un parseur XML. Écrire un parseur HTML est beaucoup moins évident, à cause de tout le HTML pourri qui traîne ici et là. Si vous vouliez écrire un parseur HTML, il vous faudrait beaucoup de travail pour obtenir un résultat correct, comme j’ai pu le constater en observant certains projets de recherche.

Laissez-moi vous raconter une histoire. J’étais à une époque rédacteur en chef d’un magazine, et j’acceptais les articles dans n’importe quel format, car nous avions tout un tas de filtres d’importation vers le logiciel de publication que nous utilisions alors. Nous acceptions entre autres le HTML, et notre système d’import en corrigeait les erreurs comme il se devait. Une fois la version papier du magazine sortie, nous la publiions également sur le site. Un des auteurs me signala un jour que les liens contenus dans son article étaient incorrects, et me demanda de les réparer. Il s’avéra que notre système d’import avait réglé les problèmes de parsing d’une manière totalement différente de celle choisie par le navigateur. Il m’a fallu beaucoup de travail pour régler le problème.

Une autre fois, un des programmes de la chaîne de publication générait du HTML qui plus tard corrigé de telle sorte qu’il faisait planter le processus un peu plus loin. La seule solution fut d’arrêter la chaîne, récupérer la sortie d’un du programme fautif dans un fichier, l’éditer manuellement, puis l’injecter dans le logiciel suivant.

L’utilisabilité, c’est le fait de vouloir faciliter la vie des utilisateurs en simplifiant leurs tâches : les rendre plus rapides, exemptes d’erreurs, et agréables. HTML a totalement raté cette mission.

XHTML

XHTML devient pertinent le jour où l’on comprend que le monde ne se limite pas à un navigateur. Nombreux sont les producteurs de XHTML qui le font parce qu’ils génèrent une sortie en XML à un endroit de la chaîne, et qu’ils souhaitent pouvoir en récupérer également un peu plus tard. Leurs bases de données comprennent le XML, leurs chaînes de production génèrent et valident du XML, et le résultat final donne du XML, sous forme de XHTML. Ils veulent juste que votre navigateur affiche leur XHTML, puisque c’est ce qu’ils produisent. C’est la raison pour laquelle je pense qu’envoyer du XHTML en text/html. Tout ce que je veux, c’est que le XHTML soit affiché, sans que rien ne viennent casser le modèle de génération du HTML.

Mais il y a plus. Le but du XML est d’autoriser un design de balises distribué. Chaque bit du récit transmis dans le markup peut être conçu par des experts dans leur domaine : graphisme, mathématiques, multimédia, formulaires… Et il existe une architecture permettant à toutes ces parties d’être liées les unes aux autres.

SVG, MathML, SMIL, XForms etc… sont le résultat de cette conception distribuée. Et si quelqu’un tombait un jour sur une niche nécessitant un langage descriptif, il serait libre de le créer. C’est un processus réellement ouvert, et il existe des manières simples, ouvertes et clairement définies de le faire, et d’intégrer leurs balises à des systèmes existants. Un des problèmes aujourd’hui avec HTML5 est qu’il est conçu comme un bloc monolithique par des gens qui ne sont en aucun cas experts dans les domaines dans lesquels ils devraient l’être.

La raison pour laquelle nous avons besoin du XHTML est que les architectures XML ont besoin de la couche hypertexte pour se brancher les unes aux autres. C’est une erreur de compréhension que de penser que XHTML 1.* n’offrait aucune porte de sortie vers de nouvelles fonctionnalités. Ces nouvelles fonctionnalités étaient SVG, SMIL, MathML etc…

La meilleure concrétisation de cette architecture fut Joost (malheureusement disparu), qui combinait des pans entiers de ces technologies afin de créer un lecteur de télévision sur IP extrêmement complet, au point que vous ne vous rendiez même plus compte qu’il tournait dans un navigateur (en l’occurrence Mozilla).

Hors des intranets, de nombreuses sociétés utilisent cette architecture pour faire leur travail, avant d’en rajouter une couche afin de le rendre disponible aux navigateurs, créant au passage une fois de plus un résultat monolithique.

Ce que je prévois aujourd’hui, c’est l’avènement de bibliothèques Javascript XML, qui rendront disponibles les contenus XML dans les navigateurs. Ces derniers deviendront alors simplement des coquilles combinant moteurs de rendu et processeurs javascript. HTML deviendra alors l’assembleur du web. HTML ne satisfait plus les besoins du monde réel. Nous avons besoin d’un langage de balises de bien plus haut niveau.

En bref, nous avons besoin de XHTML parce que 1) les générateurs de XML en produisent naturellement, 2) il y a des gens qui tirent vraiment profit de l’architecture XML.

Publié le 02 juin 2009 à 21h00 Publié sous Actualités du web

Mots clés xml, xhtml, w3c

Si cet article vous a plu, n'hésitez pas à me suivre sur Twitter.

9 commentaires sur Pourquoi choisir XHTML, par Steven Pemberton du W3C »

Par Yannick le 03 juin 2009 à 10h17 :

Merci Fred pour cette traduction. Exellent article !
Par samuel le 03 juin 2009 à 10h58 :
salut, merci pour cet article très intéressant mais j’ai quelques petites questions.
- Je ne vois pas vraiment la différence entre xhtml et html5 déjà, pour moi l’html était de xml très permissif, le xhtml n’était que la version propre et “syntaxiquement correcte” des normes de l’html, non ?
- A ma connaissance la balise video est une balise html5, existe-il un équivalent en xhtml?
- euh … je crois que c’est tout en fait
Par Thomas le 03 juin 2009 à 11h05 :
Merci pour la traduction ! Quelques erreurs (ou mauvaises tournures) :
- “qu’une gestion des ferme des erreurs”
- “C’est la raison pour laquelle je pense qu’envoyer du XHTML en text/html.” ???
Par Thomas le 03 juin 2009 à 11h09 :

D’ailleurs, j’avais vaguement entendu parler de (X)HTML5, quelqu’un sait quelque chose ?

Ça permettrait d’utiliser les nouveautés d’HTML5 dans un document plus “strict”.
Par Frédéric de Villamil le 03 juin 2009 à 11h31 :

Samuel : - HTML dérive du SGML, qui est un langage de balises extensible, tout comme XML d’ailleurs, dont dérive XHTML. Dire que XHTML est la version propre est syntaxiquement correcte de HTML est donc faux. - Vidéo n’existe pas de base en XHTML(2).

Thomas : merci, effectivement, je ne me suis pas relu (comme d’hab). Et XHTML5… jamais entendu parler. Déjà qu’entre XHTML2 et HTML5…
Par Adrien Leygues le 03 juin 2009 à 12h08 :

Salut,

@Thomas & @Fred, vous en trouverez un peu plus ici : http://www.whatwg.org/specs/web-apps/current-work/

“1.7 HTML vs XHTML” > “The second concrete syntax uses XML, and is known as “XHTML5”. When a document is transmitted with an XML MIME type, such as application/xhtml+xml, then it is processed by an XML processor by Web browsers, and treated as an “XHTML5” document. Authors are reminded that the processing for XML and HTML differs; in particular, even minor syntax errors will prevent an XML document from being rendered fully, whereas they would be ignored in the “HTML5” syntax.”
Par Nicolas F. le 03 juin 2009 à 13h17 :

Je suis pas non-plus un fan d’HTML5. XHTML est bien plus puissant et comme le dit bien l’auteur de l’article, rien n’empêchait aux détracteurs d’XHTML de l’étendre. Ce n’est que pure “politique” et ça pourrit le débat.

Mais bon, comme d’hab. je conseille aux gens sérieux d’attendre que la pâte repose et de faire le choix qui s’impose à ce moment…
Par EnZ le 03 juin 2009 à 20h29 :

Autant par moment je trouve certains de tes articles inintéressants (je ne dis pas qu’il le sont, juste que je ne me sens pas visé) mais celui là est térrible. même si ce n’est qu’une traduction, il est très intéressant ! Merci Merci.
Par Niavlys le 18 juin 2009 à 20h51 :

J’ai l’impression que tout ça c’est un peu un faux problème. Le truc qui me semble important dans HTML5, c’est les balises audio et video qui sont le prolongement logique de la balise img. Mais de toute façon, dans les versions futures des navigateurs, on pourra très bien avoir une page XHTML avec une balise video dedans, non ? Sinon, de toute façon, il me semble que XHTML devrait simplement choisir d’implémenter certaines des idées proposées par HTML5.