Quel avantage à servir du XHTML comme XML?

Bonjour,

Une lecture récente semble indiquer que du XHTML 1.0 *devrait* être servi comme XML mais *peut* l'être comme HTML.

Est-il correct de penser qu'un navigateur parsera plus facilement un XHTML conforme comme XML plutôt qu'en mode text/html?

Edit: Pourquoi servir du XHTML comme /text/html est mal:

a écrit :
Les documents envoyés en tant que text/html sont traités comme de la soupe de balises[1] par la plupart des agents utilisateurs.

C’est le point essentiel. Si vous envoyez du XHTML en tant que text/html, du point de vue des navigateurs, vous leur envoyez tout simplement de la soupe de balises. Peu importe qu’il soit valide, il sera purement et simplement traité comme s’il s’agissait de bon vieux HTML 3.2 ou d’une quelconque daube HTML.

Comme la plupart des auteurs ne testent leurs documents que sur un ou deux agents utilisateurs, plutôt que d’utiliser un validateur, cela signifie que les auteurs ne vérifient pas la validité, et par conséquent la majorité des documents actuellement sur le web qui prétendent être du XHTML sont invalides.

Voyez par exemple cette étude : http://www.goer.org/Journal/2003/Apr/index.html#results …mais si vous avez des doutes, libre à vous de menez la vôtre. Pour tout échantillon aléatoire de documents qui semblent prétendre à être du XHTML, une écrasante majorité est invalide.

Donc l’avantage principal d’utiliser du XHTML, le fait que les erreurs sont détectées tôt parce qu’il doit être valide, est perdu quand le document est envoyé en tant que text/html. (oui, j’ai bien dit la plupart des auteurs. Si vous êtes un des rares auteurs qui comprennent comment éviter les problèmes présentés dans ce document et qui valident effectivement leur code, alors ce document ne vous concerne probablement pas — consultez l’Annexe B).

Si jamais vous passez vous documents prétendument XHTML de text/html à application/xhtml+xml, vous vous retrouverez très probablement avec un nombre considérable d’erreurs XML, avec pour conséquence que vos utilisateurs ne pourront pas lire votre contenu. (voir ci-dessus : la plupart de ces documents ne sont pas valides.)

Si un utilisateur enregistre un document text/html sur son disque dur et l’ouvre ensuite en local, déclenchant ainsi le mécanisme de reniflage de type de contenu, étant donné que les systèmes de fichiers n’incluent généralement pas d’information sur le type de fichier, le document pourrait être ouvert en tant que XML, avec comme résultat possible des erreurs de validation, des différences de parsing, ou des différences d’affichage au niveau des styles. (les mêmes différences que lorsque vous envoyez le fichier un type MIME XML)

Le seul avantage réel à utiliser du XHTML plutôt que du HTML4 est qu’il est ensuite possible d’exploiter des outils XML. Cependant, si vous utilisez des outils, ces mêmes outils peuvent aussi bien produire du HTML4. Alternativement, ces outils pourraient accepter du SGML en données d’entrée à la place du XML. (SGML a dix ans de plus que XML et les outils pour l’exploiter existent depuis des années).

Le HTML 4.01 contient tout ce que contient le XHTML, il y a donc en réalité peu de raisons d’utiliser du XHTML. Il semblerait que la raison principale soit juste de « suivre le mouvement » consistant à utiliser la dernière et la (soi-disant) meilleure technologie.

Source: http://www.hixie.ch/advocacy/xhtml.fr/
Modifié par ripat (22 Dec 2009 - 13:55)

Moteur Geko:
Après quelques recherches, il semblerait que lorsqu'une page XHTML est servie comme XML (content: application/xhtml+xml), c'est le parser XML qui fait le travail plutôt que ce qu'ils appellent le "tag soup parser". Je n'ai pas trouvé d'information sur les performances relatives des deux parser mais j'aurais tendance à penser que le parser XML devrait être plus performant car ne doit pas traiter tous les cas de balises HTML mal formées.

Opera:
Pas trouvé d'info sur son parser XML et encore moins sur ses perf.

IE
Heuu... Peut-être dans IE 24. Avec un peu de chance! jusque là on est condamné à continuer à lui servir la "soupe de tag".

Bien évidemment il est absolument inutile de faire de l'xhtml. Mais je te retourne la question est-il plus utile de faire de l'html ou de l'xhtml ? Faire de l'html n'est-il pas inutile ? en faite le problème est tout simplment l'existence des 2.

Point qui sera bientôt réglé avec hml5. Il y aura en effet une version xhtml met qui devra est sorti en application xhtml/xml.

En attendant ne pas oublié qu'il y a 2-3 petites différences notamment sur les interprétations de certaines erreurs d'html entre une DTD ou une autre. Et certain style graphique par défaut ne sont identiques.

Tout ceci est un débat.

Laurie-Anne a écrit :
Bonjour,

J'ai arrêté ma lecture ici, tellement c'était idiot :
Une daube HTML ? Ah bah on est mal barré alors...


Qu'est-ce qu'il faut pas lire...

ps : les trolls normalement c'est le vendredÿ

Le mot "daube" est une mauvaise traduction. Le texte original parle de random HTML garbage. Le traducteur aurait été mieux inspiré de parler de HTML mal formé.

a écrit :
This is the key. If you send XHTML as text/html, as far as browsers
are concerned, you are just sending them Tag Soup. It doesn't
matter if it validates, they are just going to be treating it the
same was as plain old HTML 3.2 or random HTML garbage.

Quant au troll, l'auteur du texte original, Ian Hickson, n'est pas n'importe qui.

Mais tout ça ne répond pas à ma question. L'auteur ainsi que le W3C recommandent d'utiliser le mime application/xhtml+xml pour les navigateurs qui se sont présentés comme le supportant (Firefox, Safari, Opera etc...).

D'accord, mais quel en est le réel avantage. Rapidité du parsing? S'il n'y a aucun gain, ça ne sert à rien de faire du XHTML. Autant faire du HTML, bien formé de préférence.

Si vous avez des info sur le parser XML (expat) comparé au "tag soup parser", je prends.
Modifié par ripat (22 Dec 2009 - 16:56)

masseuro a écrit :
Bien évidemment il est absolument inutile de faire de l'xhtml.

Si on le l'envoie au navigateur en lui demandant de le traiter comme du text/html , alors oui, c'est inutile de faire du XHTML. Ou du moins il ne présente aucun avantage par rapport à du bon HTML. Mais alors pourquoi tout le monde s'évertue à envoyer des DOCTYPE xthml-strict, à commencer par ce site.

Pour faire "über-geek"?
Modifié par ripat (22 Dec 2009 - 17:04)

Salut,

comme ce n'est pas la première fois que cette question est posée je t'invite à lire ce sujet.

Perso j'aime bien la syntaxe xmlisée, je trouve ça plus clair, alors je fais de l'xhtml envoyé en text/html. Le jour où je ferai de l'html5, je continuerai ainsi (puisque c'est valide)…
Modifié par Patidou (22 Dec 2009 - 19:46)

Patidou a écrit :
Perso j'aime bien la syntaxe xmlisée, je trouve ça plus clair, alors je fais de l'xhtml envoyé en text/html. Le jour où je ferai de l'html5, je continuerai ainsi (puisque c'est valide)…

C'est justement ça la question. Pourquoi servir une page XHTML conforme en text/html à un navigateur qui annonce qu'il accepte le type mime application/xhtml+xml dans le header qu'il envoie au serveur?

Si le code est conforme il n'y a rien à craindre du parser XML et on peut supposer que ceux qui s'enorgueillissent de faire du xhtml-strict, et qui souvent arborent fièrement le logo W3C, produisent un code conforme non?

Il est vrai que si le code est mal formé, pas de pardon. Le parser XML du navigateur ne laisse rien passer.

Côté serveur, l'application peut décoder le champ "accept" du header envoyé par le navigateur. S'il contient application/xhtml+xml avec un q au moins égal à celui de text/html, on lui balance le prologue XML qui convient. Il existe des tas de solutions. La plus complète, celle qui tient compte du paramètre q, est celle-ci.

Deux remarques sur ce script:

- Si un UA ne renvoie pas de champ accept, PHP en mode erreur strict renvoie un warning. Il suffit d'ajouter une condition isset($_SERVER["HTTP_ACCEPT"])

- Dans le cas où le navigateur montre sa préférence pour un mime text/html, l'auteur de l'article balance un prologue HTML 4.01 ce qui l'oblige à buffériser la sortie et de remplacer les " />" par ">". Un peu lourd. Pour ma part je renvoie un prologue sans déclaration XML mais avec un DTD xhtml. Ça évite le travail de remplacement.

Mais, il n'y a pas que PHP, Apache peut aussi s'en charger par une règle de rewrite appropriée. Bien que cette solution ne tienne pas compte des préférences données par le paramètre q.

Bonjour,

Un simple ..

<?php
if (stristr($_SERVER['HTTP_ACCEPT'], 'application/xhtml+xml'))
{
  $contentType = 'application/xhtml+xml';
  $docType = '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">';
}
else {
  $contentType = 'text/html';
  $docType = '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">';
}
?>

.. résout le problème de déterminer que servir à quel navigateur.

Commencer à tenter d'adapter son code à grand renfort d'expressions régulières (or whatever) en retirant/ajoutant les slashs de fin des balises auto-fermantes par exemple, ça devient de la branlette .. (comprendre "ça sert pas à grand chose si ce n'est à auto-satisfaire son auteur").

thewebcreator a écrit :
users won’t notice any speed improvement

That's it.
Modifié par Akhilleus (23 Dec 2009 - 11:28)

Akhilleus a écrit :
Bonjour,

Un simple ..
.. résout le problème de déterminer que servir à quel navigateur.

Commencer à tenter d'adapter son code à grand renfort d'expressions régulières (or whatever) en retirant/ajoutant les slashs de fin des balises auto-fermantes par exemple, ça devient de la branlette .. (comprendre "ça sert pas à grand chose si ce n'est à auto-satisfaire son auteur").
That's it.

Non, ce simple ... ne suffit pas.

Le code que tu présentes est celui qui est le plus souvent rencontré dans les recherches Google mais imagine que le champs Accept du navigateur se présente comme suit:
text/html,application/xhtml+xml;q=0.5,application/xml;q=0.5,*/*;q=0.8

Ton bout de code lui présentera le mime application/xhtml+xml (q = 0.5) alors que le navigateur a montré sa préférence pour du text/html (q = 1). Relis bien le code proposé et tu verras qu'il en tient compte.

De plus, il est également plus propre de ne pas envoyer de déclaration XML pour du text/html.

Par contre, comme je le précise plus haut, la bufférisation pour le nettoyage des balises auto-fermantes n'est pas indispensable, et même limite "overkill". Il suffit d'envoyer un DTD xhtml.

Patidou a écrit :


Voilà. Est-ce que tous les cms sont capables de garantir un code valide à 100% lors de la rédaction du contenu?

Un CMS qui génère du code conforme oui mais tu as raison pour les sites qui incorporent tel quel du code html injecté par des utilisateurs sans nettoyage en aval.

Je continue de chercher et de tester les avantages d'un parse XML plutôt que tag soup. J'ai juste trouvé ceci. Le chargement de pages XML semblent être de deux à trois fois plus rapide que les pages HTML.

J'ai essayé de vérifier ces chiffres avec le module Dragonfly (réseau) d'Opera 10 et je ne vois pas de différences significatives entre les deux mode de parsing. Mais je ne suis pas certain de bien interpréter les données de Dragonfly.