Interprétation du DOCTYPE par IE ?

Gorkk · 12 Janvier 2005

Voilà, en écrivant un pop-up DHTML permettant d'afficher une liste de sites en description d'une div, intégré à une page XHTML, je suis tombé sur un comportement bizarre d'IE. (a priori c'est lié au DOCTYPE et non au js utilisé, mais on sait jamais).

En fait ce que j'ai codé marche très bien sous Firefox (normal ça valide, et le Console JS ne m'indique aucune erreur). Sous IE, si je mets un DOCTYPE <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> (HTML Transitional, sans préciser d'URL), ça marche impec (bien qu'en réalité ce soit du XHTML, mais bon...) (de la sorte ça passe aussi sur Firefox, mais bien sûr ça valide pas ).

En mettant le véritable DOCTYPE XHTML Strict <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">, ça valide et Firefox l'interprète correctement, mais IE ne fait plus apparaître la boîte.

Lorsque je faisais mes tests pour voir si ça passait, je mettais les deux DOCTYPE (en commençant par le Transitional) et je commentais/décommentais l'un des deux pour avoir celui pour lequel je voulais tester.

Et je me suis aperçu que, bien qu'avec le DOCTYPE XHTML Strict IE merde, avec le DOCTYPE HTML Transitional dans un commentaire HTML suivi du DOCTYPE XHTML Strict (ce qui passe toujours sans problème au validateur), IE ne merdait plus.

J'en ai donc conclus, peut-être à tord, qu'IE (Firefox je pense pas vu qu'il respecte bien les normes et que ça passe au validateur, mais faudrait probablement tester avec du code qui aura un comportement différent suivant le DOCTYPE effectif) tenait compte du contenu du commentaire HTML du début et prenait comme DOCTYPE celui défini dans les commentaires, et ignorait (ce qui est somme toute logique) la définition de DOCTYPE suivante (qui est a priori pourtant la seule qui devrait être considérée, l'autre étant commentée).

Ou alors peut-être que je fais une erreur et que des commentaires HTML avant la balise HTML ne sont pas considérés comme commentaires ?

Si quelqu'un avait des éclaircissement à ce sujet, je suis preneur. Si ce que je pense s'avère exact, ça nous donne un moyen de définir un DOCTYPE différent pour IE (ce qui peut s'avérer utile vu les différences énormes de comportement d'IE suivant le DOCTYPE).

Pour vous rendre compte par vous même, la version avec le DOCTYPE commenté est là, et celle avec juste le DOCTYPE strict ici.

(Si au passage il s'avère qu'il y a des erreurs dans mon JS, n'hésitez pas )

Modifié 12 Janvier 2005 par Gorkk

encyclo · 12 Janvier 2005

Dans les deux cas, IE et Firefox, le doctype fait changer le "rendering mode" (je sais pas comment le dire en français!) entre "Quirks Mode" et "Standards-compliance Mode". Mais, IE met standards mode seulement si le doctype (XHTML ou HTML 4.01 avec URL) est sur la première ligne. Firefox est plus correct et il permet le doctype après une declaration XML ou un commentaire.

Alors, ton script fonctionne sous IE dans quirks mode, mais pas dans le nouveau standards-compliance mode, tout simplement. Pour le doctype, c'est une bogue connue. Si tu veux continuer a utiliser quirks mode sous IE et standards sous Firefox, tu peux utiliser un prologue XML sur la première ligne, suivi du doctype:

<?xml version="1.0" encoding="iso-8859-15"?>

PS. tu as une erreur dans le meta content-type: il devrait lire "text/html" pas "application/xhtml+xml

Modifié 12 Janvier 2005 par encyclo

LaurentDenis · 12 Janvier 2005

Si au passage il s'avère qu'il y a des erreurs dans mon JS, n'hésitez pas

Le script ne passe pas dans Opera. Reste à vérifier le résultat dans Safari, Konqueror...

Il est d'autre part innaccessible au clavier. Enfin, il rend les liens inutilisables lorsque CSS est activé mais pas javascript.

Sans compter la présence dans le HTML des liens "<a href="#" class="slien" onclick="sites_close(1);">Fermer</a>" totalement dénués de sens dans n'importe quel media autre que les navigateurs graphiques avec CSS et javascript activés (navigateurs textes et vocaux, lecteurs d'écrans, mobiles, robots d'indexation, etc). Sur la séparation entre comportement et structure, voir http://pompage.net/pompe/separation/ (en français)

Autrement dit, c'est un bon exemple de javascript obstructif qui entrave l'accès à la page, affaiblit sa structure et diminue son ergonomie

Pour le doctype, c'est une bogue connue. Si tu veux continuer a utiliser quirks mode sous IE et standards sous Firefox, tu peux utiliser un prologue XML sur la première ligne, suivi du doctype:
<?xml version="1.0" encoding="iso-8859-15"?>

Non ! Surtout pas...

- comme tu le dis d'ailleurs, le prologue XML genère un bug d'IE : ce n'est pas un mécanisme de doctype switching, mais un accident.

- le prologue n'a aucun sens dans un document XHTML servi comme du HTML, ce qui est le cas ici.

Pourquoi encourager une syntaxe inappropriée ? Mieux vaut s'en tenir à une DTD abrégée qui fera basculer IE en mode quirks, sans recourir à un bug du navigateur. Et à tout prendre, une DTD HTML plutôt que XHTML (avec les modifications nécessaires dans le code de la page), dans la mesure où celle-ci n'adhère pas aux règles qualitatives du XHTML.

Gorkk · 13 Janvier 2005

Tout d'abord, merci pour les remarques, en particulier sur les nuisances à l'accessibilité provoquées par mon JS. J'essaierai de faire les modifications nécessaires pour les supprimer (j'avoue que je n'avais pas pensé à faire le test CSS sans javascript).

Je n'avais effectivement pas non plus testé ce script avec Opera. Il va donc apparemment falloir que je le fasse (je suis plutôt noveic avec le Javascript, donc je connais pas trop les différences de comportements de ces navigateurs, et j'avais pas pensé à testé Opera. Pour Konqueror ou Safari, ça risque d'être un peu dur pour moi de tester, tournant exclusivement sous Windows...)

Pour ce qui est du passage en quirks mode d'IE lorsqu'on met la déclaration xml, je le savais. Mais ce qui m'a étonné dans mon cas, c'est qu'en mettant un DOCTYPE dans un commentaire HTML suivi du DOCTYPE souhaité, IE prenait apparemment comme DOCTYPE celui qui était dans les commentaires (peut-être que Firefox également, je n'en sais rien vu qu'il se comporte pareil dans les deux cas sur ce code, et peut-être est-ce normal que les commentaires html ne soient pas considérés comme tels avant la déclaration du DOCTYPE, mais toutefois si c'est le cas, ce serait étonnant qu'un document avec deux définitions de DOCTYPE passe la validation du W3C).

PS. tu as une erreur dans le meta content-type: il devrait lire "text/html" pas "application/xhtml+xml

Veux tu dire que je devrais fournir pour IE le type "text/html" en faisant une vérification des types supportés (cf. ici) ? ('fin IE répondant qu'il supporte */* ça changerait rien pour lui).

Mon en-tête est à ma connaissance conforme aux recommendations du W3C sur les types MIME et le XHTML

'application/xhtml+xml' SHOULD be used for XHTML Family documents

(source)

- le prologue n'a aucun sens dans un document XHTML servi comme du HTML, ce qui est le cas ici.

Pourquoi encourager une syntaxe inappropriée ? Mieux vaut s'en tenir à une DTD abrégée qui fera basculer IE en mode quirks, sans recourir à un bug du navigateur. Et à tout prendre, une DTD HTML plutôt que XHTML (avec les modifications nécessaires dans le code de la page), dans la mesure où celle-ci n'adhère pas aux règles qualitatives du XHTML.

Déjà l'idéal pour moi serait d'arriver à faire fonctionner ce code pour le mode strict d'IE. Autrement, tu pourrais préciser un peu le passage concernant le "XHTML servi comme du HTML" et le "n'adhère pas aux règles qualitatives du XHTML" (surtout le deuxième passage, je ne suis pas certain de voir ce que tu veux dire, même si je pense que tu fais référence à l'accessibilité principalement, point que je compte bien régler à terme ) ?

A noter que ce bout de code est supposé être intégré par la suite dans un code plus important, là il est isolé pour la période de développement, c'est tout.

Modifié 13 Janvier 2005 par Gorkk

LaurentDenis · 13 Janvier 2005

Mon en-tête est à ma connaissance conforme aux recommendations du W3C sur les types MIME et le XHTML
'application/xhtml+xml' SHOULD be used for XHTML Family documents
(source)

(...)

Autrement, tu pourrais préciser un peu le passage concernant le "XHTML servi comme du HTML" et le "n'adhère pas aux règles qualitatives du XHTML" (surtout le deuxième passage, je ne suis pas certain de voir ce que tu veux dire, même si je pense que tu fais référence à l'accessibilité principalement, point que je compte bien régler à terme ) ?

<{POST_SNAPBACK}>

Ah... Il y a manifestement quelque-chose à éclaircir sur la notion de "type MIME" et sur ce qu'est une meta "http-equiv".

L' information de type MIME doit être associée à une ressource ((X)HTML, image, autre) au niveau HTTP, c'est à dire dans les échanges client-serveur, et non par le biais de la meta http-equiv, qui ne sera pas actuellement exploitée par les navigateurs pour choisir le mode de traitement du document (moteur HTML ou parseur XML).

La <meta http-equiv="content-type" content="...> ne fait que dupliquer cette info HTTP (c'est le rôle des meta dotées d'un attribut http-equiv par opposition aux <meta name="...">).

Elle fournit bien au serveur, en théorie, un moyen de déterminer le type MIME à associer au document dans l'en-tête HTTP Content-Type lorsque cela n'a pas été paramétré par ailleurs. Mais dans la pratique, ce mécanisme est inopérant

En revanche, cette meta joue un rôle essentiel pour préciser le type d'encodage du document. voir Spécifier l'encodage des caractères d'un document (X)HTML)

Ici, ta page est reçue et interprétée par les navigateurs comme du text/html, malgré la présence de ta meta. Tu peux facilement le vérifier en affichant les informations sur la page dans Opera ou dans Firefox, ou encore en visualisant les en-têtes HTTP envoyés par le serveur (Voir dans les Outils du Hub).

Autrement dit, pour exploiter le type MIME application/xhtml+xml, il faut intervenir au niveau serveur, dans le .htaccess, ou avec un header('Content-Type: application/xhtml+xml; charset=...'); en PHP par exemple.

Tout le monde n'ayant pas forcément la possibilité ou les compétences pour intervenir de cette manière, et tous les navigateurs n'étant pas capables d'exploiter les document application/xhtml+xml, le XHTML1.0 a été conçu de manière à pouvoir être servi et traité comme du HTML (en fait du HTML invalide) par les navigateurs, à condition de respecter une série de règles de compatibilité.

Ces règles sont indiquées dans un appendice de la spécification XHTML: Appendice C. Règles de compatibilités du HTML. Elles permettent de s'assurer que le moteur HTML du navigateur saura corriger ce qui est pour lui un HTML erroné de manière à obtenir un affichage sans "casse" (pour un exemple concret de "casse", voir ou ? ou ? Lisez les specs !.

En fait, le choix à faire est:

- faire du XHTML1.0 en gérant effectivement les deux types MIME à adresser selon la capacité du navigateur, pour le plaisir de faire du XHTML pur et dur et apprendre comme ça marche.

- faire du XHTML1.0 en s'en tenant au type text/html et en respectant les règles de compatibilité HTML, pour apprendre la syntaxe XHTML

- faire tout simplement du HTML4.01, si la priorité est de délivrer un contenu normalisé, favorisant l'accessibilité que tu veux travailler par la suite, interopérable, etc.

Voir également

XHTML1.1, beaucoup de bruit pour rien qui contient diverses choses valables également pour XHTML1.0.

Modifié 13 Janvier 2005 par LaurentDenis

Ganf · 13 Janvier 2005

> header('Content-Type: application/xhtml+xml; charset=...');

Sauf erreur les charset ne se définissent dans le type mime que pour les text/*, donc pas pour l'exemple justement

LaurentDenis · 13 Janvier 2005

> header('Content-Type: application/xhtml+xml; charset=...');

Sauf erreur les charset ne se définissent dans le type mime que pour les text/*, donc pas pour l'exemple justement

???

C'est, au contraire, l'indication d'encodage contenu dans une meta http-equiv pour un document servi en application/xhtml+xml (ou plus généralement application/xml) qui sera ignorée. Voir http://www.w3.org/TR/2002/NOTE-xhtml-media...ation-xhtml-xml

Le charset défini dans l'en-tête HTTP Content-Type est bien pertinent et recommandé (voir le lien ci-dessus).

Gorkk · 13 Janvier 2005

Merci encore pour toutes ces remarques et tous ces liens.

D'ailleurs au passage dans l'appendice sur les règles d'accessibilité, il est écrit

Vérifiez que les instructions de traitement s'éxécutent sur les agent utilisateurs. Cependant, notez également que si la déclaration XML n'est pas incluse dans un document, le document peut utiliser uniquement le jeu de caractère par défaut UTF-8 ou UTF-16.

Ca veut donc dire qu'en l'absence du prologue xml, logiquement les documents ne devraient pas tenir compte du charset défini (à part s'il est défini dans l'en-tête HTTP) non ?

Pour la spécification du type de contenu, bien que dans les liens que j'ai vu pour du XHTML 1.0 c'est toujours servi en text/html, les recommendations du W3C indique que pour toute la famille XHTML ça devrait être en application/xhtml+xml; avec tous les problèmes que ça crée pour IE (donc tant qu'à faire plutôt que de servir le document en text/html pour tout le monde, je vais plutôt le faire que pour ceux qui ne comprennent pas le application/xhtml+xml; )

En fait, le choix à faire est:
- faire du XHTML1.0 en gérant effectivement les deux types MIME à adresser selon la capacité du navigateur, pour le plaisir de faire du XHTML pur et dur et apprendre comme ça marche.

- faire du XHTML1.0 en s'en tenant au type text/html et en respectant les règles de compatibilité HTML, pour apprendre la syntaxe XHTML

- faire tout simplement du HTML4.01, si la priorité est de délivrer un contenu normalisé, favorisant l'accessibilité que tu veux travailler par la suite, interopérable, etc.

Je vais partir sur la première solution (en grande partie pour me forcer à apprendre, et puis pour faire du HTML valide, il faudrait que je reprenne l'habitude de mettre les balises en majuscules et de pas fermer les balises simples )

En tout cas merci pour tous vos conseils (d'ailleurs je vais aller faire un tour dans la section JS, y a sûrement des infos sur la manière dont Opera l'interprète, histoire de le rendre compatible Opera).

/me est parti pour rendre ce script accessible et fonctionnel pour tout le monde, même s'il lui faut plusieurs jours

encyclo · 14 Janvier 2005

'application/xhtml+xml' SHOULD be used for XHTML Family documents

Ceci est l'avis du W3C sur la question, mais il reste l'implementation. IE ne comprend pas le application/xhtml+xml. Googlebot, MSNBot et Yahoo Slurp ne comprennent pas le application/xhtml+xml non plus. Ce qui reste pour l'instant, c'est Opera et Mozilla/Firefox. Mais si on regarde le Mozilla Web Author FAQ, il dit ceci:

However, if you are using the usual HTML features (no MathML) and are serving your content as text/html to other browsers, there is no need to serve application/xhtml+xml to Mozilla. In fact, doing so would deprive the Mozilla users of incremental display, because incremental loading of XML documents has not been implemented yet. Serving valid HTML 4.01 as text/html ensures the widest browser and search engine support.

C'est clair que même pour Mozilla (et Opera, c'est pareil), ce n'est pas du tout une bonne idée d'utiliser le application/xhtml+xml.

Ça commence à être un vieux débat. Je ne suis pas contre le XHTML, mais quand je peux choisir, je préfère toujours le HTML 4.01. XHTML 1.x sans le application/xhtml+xml comporte presque'aucun avantage sur le HTML 4.01, et avec le application/xhtml+xml, il comporte beaucoup de désavantages.

Sur des questions spécifiques:

Ca veut donc dire qu'en l'absence du prologue xml, logiquement les documents ne devraient pas tenir compte du charset défini (à part s'il est défini dans l'en-tête HTTP) non ?

Dans le cas que le document est servi avec le application/xhtml+xml, oui, mais quand c'est le text/html, non c'est comme le HTML. C'est toujours mieux de déclarer le charset dans les headers HTTP. J'ai dit que la balise meta était incorrect parce qu'il n'est pas possible de spécifier le mime type dans une balise meta quand c'est autre chose que text/html après l'envoi des headers HTTP. Si c'est en text/html, alors le document est traité comme du HTML (mal-formé!), et alors la balise meta donne la mauvaise type mime (et ne la changerait pas). C'est pas bien expliqué, mes excuses! (le français, ce n'est pas ma langue maternelle).

- le prologue n'a aucun sens dans un document XHTML servi comme du HTML, ce qui est le cas ici.

Pourquoi encourager une syntaxe inappropriée ? Mieux vaut s'en tenir à une DTD abrégée qui fera basculer IE en mode quirks, sans recourir à un bug du navigateur. Et à tout prendre, une DTD HTML plutôt que XHTML (avec les modifications nécessaires dans le code de la page), dans la mesure où celle-ci n'adhère pas aux règles qualitatives du XHTML.

On pourrait dire que le XHTML 1.x avec le mime type text/html, c'est déjà "une syntaxe inappropriée", mais je ne suis pas en désaccord avec le commentaire. J'ai proposé la "solution" du prologue XML un peu à la legère, et tu as raison, ce n'est pas idéal.

Modifié 14 Janvier 2005 par encyclo

Gorkk · 14 Janvier 2005

Dans le cas que le document est servi avec le application/xhtml+xml, oui, mais quand c'est le text/html, non c'est comme le HTML. C'est toujours mieux de déclarer le charset dans les headers HTTP. J'ai dit que la balise meta était incorrect parce qu'il n'est pas possible de spécifier le mime type dans une balise meta quand c'est autre chose que text/html après l'envoi des headers HTTP. Si c'est en text/html, alors le document est traité comme du HTML (mal-formé!), et alors la balise meta donne la mauvaise type mime (et ne la changerait pas). C'est pas bien expliqué, mes excuses! (le français, ce n'est pas ma langue maternelle).

<{POST_SNAPBACK}>

Si c'est bon tu as été clair .

En tout cas ce fil m'a éclairé sur pas mal de points, et avec vos remarques m'a permis de rendre mon script fonctionnel déjà sur les IE, Firefox et Opera (faudra que j'arrive à tester sur Safari et Konqueror ), ainsi qu'à le rendre accessible pour des personnes sans support JS (ou JS désactivé) mais avec le support CSS. Donc merci beaucoup. D'ailleurs un des liens donnés m'a fait comprendre la nécessité de la séparation structure / fonctionnement (autrement dit, pas de JS en ligne dans mon XHTML), et surtout m'a permis de voir comment l'obtenir. C'est vrai que c'est quand même mieux quand, comme pour les styles avec les CSS, le comportement défini par les JS est défini de façon dissociée de la structure

Par contre mon interrogation du départ reste (sauf si je suis passé au travers de la réponse ) : dans le cas que j'exposais au début (ie. que IE semblait prendre en compte le DOCTYPE donné entre commentaires HTML), IE interprète-t-il bien un éventuel DOCTYPE mis entre commentaires HTML ? Est-ce tout simplement que des commentaires HTML avant le DOCTYPE (voire avant la balise html) ne sont pas (du moins pas censés, les différentes implémentations c'est autre chose ) considérés comme tel ?

LaurentDenis · 14 Janvier 2005

Par contre mon interrogation du départ reste (sauf si je suis passé au travers de la réponse ) : dans le cas que j'exposais au début (ie. que IE semblait prendre en compte le DOCTYPE donné entre commentaires HTML), IE interprète-t-il bien un éventuel DOCTYPE mis entre commentaires HTML ? Est-ce tout simplement que des commentaires HTML avant le DOCTYPE (voire avant la balise html) ne sont pas (du moins pas censés, les différentes implémentations c'est autre chose ) considérés comme tel ?

<{POST_SNAPBACK}>

La spécification HTML4.01 est claire sur la présence de commentaires avant la DTD:

An HTML 4 document is composed of three parts:
1. a line containing HTML version information,

2. a declarative header section (delimited by the HEAD element),

3. a body, which contains the document's actual content. The body may be implemented by the BODY element or the FRAMESET element.

White space (spaces, newlines, tabs, and comments) may appear before or after each section. Sections 2 and 3 should be delimited by the HTML element.

Le code suivant est donc tout à fait admissible:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"

"http://www.w3.org/TR/html4/strict.dtd">

<html lang="fr">

Normalement, la première DTD (transitional abrégée) doit être ignorée, et le document obéit à la seconde DTD (stricte complète).

Mais pour ce qui est du mode de rendu Quirks ou Strict, IE6.0 a un bug bien particulier : la présence de quoi que ce soit avant la DTD le fait basculer en mode Quirks, quelque-soit la DTD.

(C'est ce qui se produit avec un prologue XML)

Donc, dans ton cas:

- IE n'interprète pas la DTD mise en commentaires

- Mais il passe en mode Quirks parce que la page ne commence pas par la DTD

Tu peux t'en assurer facilement en inversant l'ordre de tes DTD. IE repasse en mode de rendu strict avec:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
   "http://www.w3.org/TR/html4/strict.dtd">
<!-- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> -->

Modifié 14 Janvier 2005 par LaurentDenis

Gorkk · 14 Janvier 2005

Mais pour ce qui est du mode de rendu Quirks ou Strict, IE6.0 a un bug bien particulier : la présence de quoi que ce soit avant la DTD le fait basculer en mode Quirks, quelque-soit la DTD.

(C'est ce qui se produit avec un prologue XML)

Donc, dans ton cas:

- IE n'interprète pas la DTD mise en commentaires

- Mais il passe en mode Quirks parce que la page ne commence pas par la DTD

<{POST_SNAPBACK}>

OK, je croyais que le passage en quirks était juste du à la présence du prologue xml et non simplement à la présence de quelque chose avant le DOCTYPE.

Connexion

Interprétation du DOCTYPE par IE ?

Sujets conseillés

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Veuillez vous connecter pour commenter