Pourquoi choisir XHTML, par Steven Pemberton du W3C

Traduction d'une tribune de Steven Pemberton, chairman des groupes de travail HTML et formulaires au W3C. Elle passe en revu les raisons pour lesquelles il faut choisir XHTML.

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.

Molly E. Holzschlag : 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...

  1. On m'a demandé de créer XHTML et je l'ai fait.

  2. 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".

  3. J'ai à plusieurs reprises tenté de faire corriger quelques unes des pires erreurs de XML, et pas toujours avec succès.

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

"Pour un langage de programmation, le laxisme est une catastrophe. Pour une page HTML, c'est juste un désagrément, même si..."

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 :

  1. J'écris ma page.
  2. Je regarde ce que ça donne dans mon navigateur.
  3. Ç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 de 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 aimeraient 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 était 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 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'erreur, et agréables. HTML a totalement raté cette mission.

XHTML devient pertinent le jour où l'on comprend que le monde ne se limite pas à un navigateur

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 l'utilisent 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 n'envoyer que du XHTML en text/html. Tout ce que je veux, c'est que le XHTML soit affiché, sans que rien ne vienne 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.

Article publiée sous licence Creative Commons par Frédéric de Villamil