Du XHTML 1.1 envoyé au format text/html

[Benoit]

C'est intéressant dans le sens où il commence par traiter l'article de troll pour ensuite dire à peu près la même chose que lui

J'ai trouvé dans les liens donnés http://www.w3.org/MarkUp/2004/xhtml-faq.html#texthtml qui fait une petite remarque particulièrement intéressante :

XHTML 1.1 is an updated version of XHTML 1.0 strict

Personnellement, j'en déduirais que le mode de compatibilité HTML devient de facto limité aux autres modes (transitional et frameset), puisque le mode strict a connu une mise à jour qui le rend incompatible avec HTML. Et j'éviterais par conséquent tout envoi de XHTML 1.0 Strict en text/html, pour éviter les problèmes de copier-coller mentionné par Ian Hickson dans son annexe B (qui est probablement la seule partie du document qui s'adresse aux gens qui discutent ici).

Resteraient trois choix raisonnables (selon le public visé) sans hack ni détection du navigateur :

• HTML 4.01 Strict (text/html)
• XHTML 1.0 Transitional + Annexe C (text/html)
• XHTML 1.1 Strict (application/xhtml+xml)

Le dernier choix vous limite bien sûr aux navigateurs modernes, dont IE même dans sa version 7 ne fait pas partie

[Alan]

C'est intéressant dans le sens où il commence par traiter l'article de troll pour ensuite dire à peu près la même chose que lui

Salut,
Il partage peut être un de ses constats mais n'en tire pas la même conclusion

On peut choisir XHTML 1.0 strict en text/html tout en restant raisonnable (comme le font beaucoup de spécialistes des standards)

A+

[GizMecano]

Hello,

On peut choisir XHTML 1.0 strict en text/html tout en restant raisonnable (...)

Bon, ce que je ne comprends pas, et depuis le début, c'est fondamentalement les différences d'utilisation à envisager pour se permettre de choisir l'une ou l'autre possibilité.

Je suis peut-être un peu lent, voire terriblement néophyte, voire un néophyte terriblement lent, mais la plupart des documents que j'ai pu lire d'après les liens mentionnés depuis le début de ce fil (en tout cas de cette arboresence spécifique) entrent dans des considérations techniques hermétiques sans donner d'exemples concrets.

Je ne sais pas, mais pour éviter de faire le mauvais choix, peut-être serait-il bon d'avoir un rappel clair, concis, bref, des implications différentes, et si possible par l'exemple. Et là, bien entendu, je ne me mets pas au niveau des développeurs dont la plupart d'entre-vous êtes, mais plutôt des amateurs dans mon genre...

Merci.

Ciao,

[FF_Olivier]

Bon, ce que je ne comprends pas, et depuis le début, c'est fondamentalement les différences d'utilisation à envisager pour se permettre de choisir l'une ou l'autre possibilité.

Servir du XHTML 1.0 : http://www.w3.org/International/article ... ew.fr.html
Annexe C : http://www.w3.org/TR/2002/REC-xhtml1-20 ... guidelines

[martin]

Bon, ce que je ne comprends pas, et depuis le début, c'est fondamentalement les différences d'utilisation à envisager pour se permettre de choisir l'une ou l'autre possibilité.

Je rappelle quand même l'essentiel, la différence entre html et xhtml.

xhtml c'est html réécrit en xml.

Si le document n'a pas besoin d'être du xml, pour le mêler avec d'autres xml (svg, mathml,...), lui faire des transformations xslt, ou tout autre traitement ou besoin, il n'y a aucun bénéfice à ce qu'il ne soit pas en html.

Si on a besoin qu'il soit du xml pour une des raisons citées, il ne sera traité en tant que tel uniquement si il est servi en 'application/xhtml+xml'.

Donc faire du xhtml servi en html n'a absolument aucun intérêt.

[Alan]

Salut GizMecano,

Tu peux lire ce texte qui est assez simple d'accès :
Les DTD HTML4.01 et XHTML1.0 : comment choisir ?

[Benoit]

On peut choisir XHTML 1.0 strict en text/html tout en restant raisonnable (comme le font beaucoup de spécialistes des standards)

Je pense que la question n'est plus de savoir si on peut, mais si ça a un quelconque intérêt. Moi je trouve que non.

Les solutions à base de négotiation de contenu et de transformations XSL étant hors de portée du néophyte (et souvent de l'hébergement lui-même), je pense que les propositions raisonnables sont celles que j'ai citées (moins la solution XHTML 1.1 qui est plus théorique qu'autre chose, à moins qu'on désire volontairement se couper d'IE).

Vous voulez un affichage rapide et passe-partout ? Utilisez HTML 4.01 Strict.

Vous voulez faire un pas vers XHTML (tout en sachant que vous devrez vous limiter à la version compatible HTML) ? Utilisez XHTML 1.0 Transitional et respectez l'annexe C.

Servez le tout en text/html, toujours et pour tout le monde. Si vous ne comprenez pas cette phrase c'est que vous êtes dans le bon, c'est comme ça que ça fonctionne quand on ne fait rien

[Alan]

Je ne pense pas non plus que ce soit une simple question de possibilité, c'est pourquoi j'ajoutais "tout en restant raisonnable".

En revanche, je ne vois aucune raison de conseiller HTML en strict, mais XHTML en transitional. D'autant plus qu'au niveau HTML ou XHTML, les différences entre Strict et Transitional sont les mêmes.

[Benoit]

En revanche, je ne vois aucune raison de conseiller HTML en strict, mais XHTML en transitional. D'autant plus qu'au niveau HTML ou XHTML, les différences entre Strict et Transitional sont les mêmes.

Il y a deux aspects à cette idée. La première est comme je le disais plus haut que le XHTML Strict a connu une mise à jour avec XHTML 1.1. Symboliquement, c'est donc dépassé et obsolète, c'est pas la "dernière chose possible". Par contraste, XHTML 1.0 Transitional est la dernière chose qu'on puisse faire dans le domaine.

Le deuxième aspect est que pour être compatible HTML on fait d'importantes concessions vis-à-vis du XML. Utiliser le mot "Transitional" au lieu de "Strict" permettrait de mieux garder cette idée en mémoire, de se souvenir qu'on est toujours en phase de transition justement.

Un effet de bord intéressant est que si quelqu'un vient copier-coller sans rien comprendre on ne se retrouve pas avec des documents invalides marqués "Strict" (ce qui est un des problèmes soulevés par Ian Hickson).

[Alan]

La seule chose à se demander, c'est si l'on souhaite ou l'on a besoin d'utiliser des éléments ou attributs qu'autorise transitional (iframe, target, align etc...). Sinon il n'y a aucune raison de ne pas utiliser Strict en XHTML 1.0

Je vois mal ce que viennent faire des considérations d'ordre symbolique ou mnémotechnique là-dedans.


Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

[Sébastien Guillon]

Je pense que les règles de l'Annexe C de XHTML 1.0 s'appliquent à toutes les déclinaisons de XHTML 1.0, quel que soit le DOCTYPE. Un document XHTML 1.0 strict, servi en text/html, qui appliquerait ces règles serait donc OK pour le W3C.

Ce n'est pas le cas pour le XHTML 1.1 qui est toujours décrit comme devant être servi en application/xhtml+xml.

Pour un débutant, qui ne maîtrise pas toutes les implications, la meilleure solution est toujours de créer des pages en HTML et de les servir avec le type approprié (le seul) : text/html.

Quant à la différence entre transitional et strict, que ce soit en HTML ou en XHTML, outre les éléments qui disparaissent en "strict", il existe (et de façon notoire dans IE) des différences au niveau de l'application de CSS.

En clair les navigateurs appliquent un mode de rendu strict avec un DOCTYPE strict et un mode de rendu dit "compatible" (ou semi-standard en fonction des AU) avec les DOCTYPEs transitional et frameset.

Donc il est toujours préférable pour un site qui veut utiliser efficacement CSS de choisir un DOCTYPE strict.

Ensuite le choix de XHTML ou de HTML est le plus souvent dicté par un effet de mode, voir de « suivisme ». Il n'y a pas de honte à ça, la plupart des développeurs web (et même les meilleurs) ont commencé en s'insiprant de l'existant, bon ou mauvais.

La tentation du XHTML est trop forte pour espérer que tous les débutants se contentent de HTML 4.01 strict, bien que pour près de 100% des cas ce soit le meilleur choix.

@GizMecano

Pour résumer, tu es en porte-à-faux avec les recommandations (et autres textes) du W3C en servant tes pages XHTML 1.1 comme tu le fais actuellement (en text/html). Ton code est valide mais la page n'est pas servie correctement.

IE (y compris la future version 7) ne gère pas les documents en vrai XML et accessoirement ne reconnaît pas application/xhtml+xml, d'où la nécessité de lui servir autre chose, par exemple en utilisant une négociation de contenu.

Si tu ne sais pas comment gérer une négociation de contenu, tu peux tout simplement changer de DOCTYPE et passer à XHTML 1.0, sans changer le moins du monde le reste de ton code.

Si tu veux te lancer dans la négociation de contenu tu peux commencer par le code PHP que j'ai donné en début de fil. Mais ce code n'est que le début : la détection.

entrent dans des considérations techniques hermétiques sans donner d'exemples concrets.

Dans ce cas relis-les et fais quelques tests. Si tu veux des explications plus précises, dis-nous au moins ce que tu ne comprends pas.

Pour la différence entre application/xhtml+xml et text/html il y a entre autre la gestion draconienne des erreurs héritée de XML. Voici ce qui arrive en application/xhtml+xml à un document XHTML mal formé (à tester dans un navigateur moderne évidemment, ou dans IE pour voir comment il gère le XHTML véritable).


Message envoyé avec : Opera/8.53 (Windows NT 5.1; U; fr)

[Alan]

Quant à la différence entre transitional et strict, que ce soit en HTML ou en XHTML, outre les éléments qui disparaissent en "strict", il existe (et de façon notoire dans IE) des différences au niveau de l'application de CSS.

Salut,
C'est peut être notoire ces différences pour IE selon que le DOCTYPE soit en Strict ou Transitional, mais je n'en connais aucune.
Est-ce que tu as un seul exemple à donner concernant IE ? (hormis le cas particulier du Doctype HTML 4.01 transitional sans URL, qui fait travailler IE en Quirks mode. Mais là c'est une chose différence de ce dont tu parles)

[martin]

j'appuie complètement Sébastien Guillon sur le basculement du rendu en quirk.

Mais dans les faits, les raisons sont plus vicelardes que simplement la présence de tel ou tel doctype pour obtenir ce basculement.

Exemples (pour IE6 dans tous les cas) :

html 4.01 strict avec le bon doctype : mode standard
html 4.01 transitional avec doctype complet : mode standard
html 4.01 transitional avec doctype sans url : mode quirk

xhtml 1.0, avec doctype et entête xml: quirk
xhtml 1.0, avec doctype, sans entête xml : standard

L'essai met en évidence le mode de calcul de dimensions des boites, mais il y a évidement d'autres changements qui surviennent en mode quirk.

[Alan]

Salut Martin,

Je connais bien sûr les différences de rendu chez IE entre Quirks mode et Strict mode, mais ce que j'aimerais bien bien savoir, c'est ce dont parle Sébastien : les différences pour Internet Explorer selon que le DOCTYPE est en Transitional ou Strict, hormis le cas particulier (je l'ai dit) du HTML transitional sans URL (qui fait basculer en Quirks mode).

Je te signale d'ailleurs que ta deuxième page, « html 4.01 transitional avec doctype complet » est également sans URL. Comme la troisième...

[martin]

Je ne prétendais nullement être exhaustif , juste mettre en évidence que le choix de doctype n'était pas suffisant dans tous les cas pour basculer IE en quirk.

Les 2 exemples xhtml ont un doctype correct, l'un bascule en quirk uniquement à cause de la présence de l'entête xml.

Les exemples html (dont celui avec l'erreur que tu signales , et corrigé), montre qu'un doctype transitionnel complet (avec l'url) ne fait pas basculer IE en quirk.

Des listes plus exhaustives (choisis au pif sur gogole) :
http://wellstyled.com/html-doctype-and- ... -mode.html
http://www.meyerweb.com/eric/dom/dtype/dtype-grid.html