Pourquoi pas XHTML5?

53

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?

— jameshfisher
source

6

+1 Je constate que je ne suis pas le seul à être frustré par la perte de tous les avantages XML en HTML5.

— Arseni Mourzenko le

Honking bonne question, bien posée.

— Konrad Rudolph le

1

J'espère que je ne suis pas le seul à être heureux de la perte de tous les inconvénients de XML en HTML5. Par exemple, comparons un HTML5 valide à un XHTML valide. HTML5 <!DOCTYPE html>Hello World

<?xml version="1.0" encoding="iso-8859-1"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0  Transitional//EN" "DTD/xhtml1-transitional.dtd"><html xml:lang="en" lang="en" xmlns="http://www.w3.org/1999/xhtml"><head><title></title></head><body>Hello World</body></html>

— :,

@zzzzBov, vous n'êtes certainement pas le seul à en être content, et c'est pourquoi j'ai posé cette question en premier lieu. Aussi: vous n'écririez pas sérieusement <!DOCTYPE html>Hello World, n'est-ce pas? Essayez cela sur ce validateur .

— jameshfisher

1

@eegg, apparemment , vous avez pas lu la spécification sur les balises de départ en option , parce que je sérieusement voudrais écrire <!DOCTYPE html>Hello World!, comme il est parfaitement valide HTML5. Des documents plus courts signifient moins de surcharge de bande passante, ce qui représente une économie importante pour les grandes entreprises (avez-vous vu ce que Google envoie pour www.google.com?).

— zzzzBov

25

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

— prothèse
source

18

Ouais. Mon résumé de cette histoire serait le suivant: "Hé, personne ne se conforme à la spécification. Nous pourrions peut-être les faire respecter la spécification en précisant que les personnes peuvent commettre les erreurs de leur choix. Tous nos documents seront enfin exempts d'erreur. et conforme aux normes. " Rien de bon ne peut venir de l'écriture d'une spécification avec l'hypothèse initiale que personne ne la respecte.

— jameshfisher

1

@ eegg, votre dernière ligne montre votre ignorance de la réalité. Beaucoup de bons ont déjà été obtenus en supposant que personne n'est parfait . Plutôt que de dire que "si vous faites une erreur, tout est cassé", il est écrit: "si vous faites [ce type d'erreur], alors [ce résultat] est ce qui devrait arriver". Combien de livres y aurait-il sur nos étalages s'ils devaient avoir une orthographe, une ponctuation et une grammaire correctes à 100% pour être publiés?

— zzzzBov

6

@zzzzBov, votre analogie avec les livres publiés est étrange. Pourquoi un analyseur HTML devrait-il être plus indulgent qu'un analyseur pour [tout autre langage ici], lorsqu'une erreur de syntaxe est rencontrée avec un message d'erreur? Imaginez le chaos dans lequel nous serions si nos compilateurs C faisaient de leur mieux pour réinterpréter en silence une syntaxe altérée.

— jameshfisher

@eegg, je peux imaginer ce qui se produirait si un analyseur syntaxique d'une autre langue réagissait plus facilement aux erreurs de syntaxe: nous passerions moins de temps à rechercher des crochets mal placés, des points-virgules manquants et davantage à saisir du code fonctionnel. Je ne dis pas que les bons programmeurs ne créeraient toujours pas leurs programmes bien formés, mais cela aiderait certainement les programmeurs médiocres à écrire du code de travail. Un Cprogramme ressemblerait probablement beaucoup plus à un Pythonprogramme en ce sens que les points-virgules et les crochets pourraient pour la plupart disparaître, et qu'il ne resterait que le code important.

— zzzzBov

“La ressource demandée /past.htmln'est plus disponible sur ce serveur et il n'y a pas d'adresse de transfert.”

— Marco

6

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

— Deadalnix
source

Définir le "bon jazz". Autant que je sache, l'analyse HTML en XML ne présente aucun avantage. Générer et transformer sont d’autres aspects, cela peut être pratique, mais l’analyse en elle-même n’offre pas d’avantages, mais seulement des inconvénients (elle rend fatals les insectes cosmétiques).

— Joeri Sebrechts le

3

@Joeri Le fait qu'il soit beaucoup plus facile à analyser est un avantage dans mon livre, pour diverses raisons (l'analyse stricte facilite la recherche des erreurs, un meilleur support des outils car les outils sont plus faciles à écrire, la désinfection plus facile des entrées, etc.).

— Konrad Rudolph le

Vous pouvez également fournir des fonctionnalités non disponibles en HTML standard, comme micin xhtml avec d'autres contenus xml, et utiliser généralement toutes les fonctionnalités xml, les espaces de noms par exemple. Les analyseurs HTML sont capables de corriger un code source incorrect - des bugs esthétiques tels que vous les appelez -, mais ces correctifs ont un prix. Le prix est que le navigateur doit savoir ce qu’il est susceptible de trouver dans le code, limitant ainsi les fonctionnalités disponibles.

— deadalnix

3

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.

— Michael Kay
source

3

L'histoire de la négligence concurrente des navigateurs est assez vraie. Mais voici la chose: c'est pourquoi les geeks des normes existent. Si tous les navigateurs avaient respecté les règles du jeu dès le début, des organisations comme le W3C n'auraient pas besoin d'être là pour garder le contrôle de la situation. Le but des normes est le contrôle des dégâts; le fait que l'organisme de normalisation accepte et accepte les négligences va à l'encontre de son objectif même.

— jameshfisher

1

@eegg: HTML5 redéfinit les règles d'analyse pour rendre toutes les entrées valides tout en ayant des conséquences prévisibles. Si les erreurs de syntaxe sont impossibles, toute une classe de bogues est exclue dès le début. La capacité de XML à avoir des erreurs d’analyse est un défaut de conception et doit être reconnue comme telle.

— Joeri Sebrechts

1

@ Joeri, votre position semble être celle de la spécification HTML5, poussée à sa conclusion logique insensée. "HTML5 redéfinit les règles d'analyse pour rendre toutes les entrées valides" - ce n'est pas le cas. Le concept d'erreur d'analyse existe toujours. "Si les erreurs de syntaxe sont impossibles, toute une classe de bogues est exclue dès le début" - peut-être s'agit-il d'une parodie? Cette logique est ce que je paraphrase sarcastiquement dans mon commentaire à la réponse de @pthesis. Oui, la classe d' erreurs de syntaxe est supprimée pour être remplacée par une classe plus grande d' erreurs de correction de la syntaxe du navigateur .

— jameshfisher

2

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.

— Dean Harding
source

Sur la spécification HTML4 , oui. Mais mon point est que XHTML1.1 a déjà amélioré cela. Les outils / bibliothèques pour manipuler HTML ont tendance à ressembler à BeautifulSoup - alors que de merveilleux outils, ils devraient mourir avec les pages pour lesquelles ils ont été créés.

— jameshfisher

1

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

— JacquesB
source