Pourquoi pas XHTML5?

Donc, HTML5 est le grand pas en avant, me dit-on. Le dernier pas en avant que nous avons franchi, à ma connaissance, a été l'introduction de XHTML. Les avantages étaient évidents: simplicité, rigueur, possibilité d'utiliser des analyseurs syntaxiques et des générateurs XML standard pour travailler avec des pages Web, etc.

Comme il est étrange et frustrant de constater que HTML5 annule tout cela: encore une fois, nous travaillons avec une syntaxe non standard; encore une fois, nous devons gérer l'historique des bagages et la complexité de l'analyse; encore une fois, nous ne pouvons pas utiliser nos bibliothèques, analyseurs, générateurs ou transformateurs XML standard; et tous les avantages introduits par XML (extensibilité, espaces de nom, normalisation, etc.), que le W3C a mis une décennie à faire valoir pour de bonnes raisons, sont perdus.

Bien, nous avons XHTML5, mais il semble qu’il n’ait pas gagné en popularité, contrairement à l’encodage HTML5. Voir cette question SO , par exemple. Même la spécification HTML5 indique que HTML5, et non XHTML5, "est le format suggéré par la plupart des auteurs".

Est-ce que je me trompe? Sinon, pourquoi suis-je le seul à ressentir cela? Pourquoi les gens choisissent-ils HTML5 plutôt que XHTML5?

Je recommanderais de lire Comment sommes-nous arrivés ici? . Mark Pilgrim donne une excellente et brève histoire du HTML jusqu'au HTML5.

Toutefois, si j'ai bien compris, de nombreuses pages Web ne tirent même pas parti du "X" de XHTML car elles ne spécifient pas le type MIME approprié.

Si vous produisez du code html5 compatible xml et que vous les envoyez avec le type mime xml, alors l'analyseur xml sera utilisé pendant tout le temps que le bon jazz revient;)

EDIT: voyez ça pour plus d’informations: http://wiki.whatwg.org/wiki/HTML_vs._XHTML

HTML5 est la conclusion logique et inévitable des navigateurs qui adoptent la loi de Postel ("Soyez libéral dans ce que vous acceptez").

Une fois qu'un navigateur disposant d'une part de marché suffisante adopte ce principe, d'autres sont contraints de faire de même, non seulement en étant libéraux en acceptant des contenus non conformes, mais également en les rendant de la même manière que leurs concurrents. HTML5 est le résultat logique de cette situation: les éditeurs de navigateurs ont décidé que, dans la mesure où ils ne rejetteraient aucun contenu comme étant invalide (du moins, pas au niveau HTML - javascript est une autre affaire!), Ils pourraient tout aussi bien s'asseoir autour de vous. table et convenir d’une interprétation de tout ce que l’auteur du contenu pourrait leur adresser. Dans cet environnement, ils n'ont pas réagi avec gentillesse aux geeks des normes en leur disant que si seulement ils avaient rejeté le contenu mal formé dès le départ, ils n'auraient pas été mis dans ce pétrin.

Vous et moi pouvons donc crier de côté et dire aux vendeurs de navigateurs et à leurs utilisateurs que le monde aurait été meilleur si ils n’avaient pas cru John Postel, mais le mal est fait et il est très difficile de le réparer.

La spécification HTML5 a été considérablement améliorée par rapport à la spécification HTML4. En particulier, le traitement des conditions d'erreur et des balises non valides est en fait standardisé, ce qui signifie que tous les navigateurs qui implémentent correctement la norme gèrent les balises non valides de la même manière.

Le HTML est écrit par les humains le plus souvent (généralement en conjonction avec une sorte de langage basé sur des modèles), et les humains font des erreurs. Tant que tous les navigateurs traitent les erreurs de syntaxe de la même manière, la règle "soyez libéraux dans ce que vous acceptez" est parfaitement acceptable.

Il n’ya vraiment aucun avantage à produire du code XML valide, car les outils et les bibliothèques permettant de gérer le langage HTML sont (presque) tout aussi facilement disponibles, et le langage HTML est plus facile à écrire pour les humains que le langage XML.

De toute façon, vous ne tirerez jamais les avantages d’un analyseur syntaxique plus simple ou d’outils XML standard.

Il existe des milliards de pages sur le Web en HTML, certaines d'entre elles sont écrites par des personnes mortes depuis longtemps, elles ne seront donc jamais mises à jour en XML. Donc, si vous voulez créer un agent utilisateur généralement utile, vous devez quand même être en mesure d'analyser l'ancien code HTML. On peut soutenir que XHTML introduit seulement une complexité supplémentaire puisqu'il nécessite un nouveau mode d'analyse en plus de l'analyse HTML que vous devez déjà prendre en charge.

Côté serveur, vous pouvez toujours tirer parti des outils XML, par exemple. générer du XHTML en utilisant XSLT. Mais si vous n'utilisez pas spécifiquement une chaîne d'outils XML, il n'y a aucun avantage à utiliser la syntaxe XML plutôt que simplement HTML.

(Vous n'êtes pas sûr que HTML soit une syntaxe "non standard". La syntaxe de HTML est spécifiée minutieusement dans la spécification HTML5, il s'agit donc tout autant d'une syntaxe standard que XML.)