Confusion elements/balises pour IE

Olivier Miakinen nous a dit le 10/12/2004 12:36:

Je lance un nouveau fil, car je viens de constater un comportement
particulièrement bizarre avec Internet Explorer 6.

[snip]

Vu qu'il y a des blancs et des sauts de ligne entre mes balises, je ne
suis pas surpris par les #text. Mais maintenant voilà ce que donne
Internet Explorer 6 :
INPUT
/INPUT
#text
INPUT
/INPUT
#text

Euh, on peut voir le code que tu utilises ?
Car ce serait vraiment un bug grave là :o)

--
Bobe (Aurélien Maille)
http://webnaute.net

"la vie d'un geek est un combat perpétuel contre l'imperfection"

Je lance un nouveau fil, car je viens de constater un comportement
particulièrement bizarre avec Internet Explorer 6.

J'ai un bout de code HTML qui contient ceci (en simplifiant un peu) :
<div>
<input type="button" value="détail"></input>
<input type="checkbox"></input>
</div>

J'ai aussi un bout de code JavaScript, à base de firstChild et
nextSibling, qui me liste l'ensemble des enfants du <div>, et qui
affiche leur nodeName.


Voici ce que donne Netscape 7 :
#text
INPUT
#text
INPUT
#text

Vu qu'il y a des blancs et des sauts de ligne entre mes balises, je ne
suis pas surpris par les #text. Mais maintenant voilà ce que donne
Internet Explorer 6 :
INPUT
/INPUT
#text
INPUT
/INPUT
#text

Depuis quand une balise </input> est-elle un élément ?

Surtout depuis quand un nom de balise peut-il commencer par / !

Bien évidemment, pour confirmer, j'ai rajouté du texte entre les balises
d'ouverture et de fermeture de l'élément input. Avec NS7, même résultat,
tandis qu'avec IE6 cela me rajoute un n½ud texte entre l'élément "INPUT"
et l'« élément "/INPUT" »...

Voilà ce que c'est de jouer avec des interdits !

La DTD HTML 4.xx précise :
<!ELEMENT INPUT - O EMPTY>
i.e. l'élément input ne peut avoir de fils ! En toutes lettres dans la
traduction française de la norme HTML 4 :
"Balise de début : requise, Balise de fin : interdite"

Par ailleurs, dans les XHTML1.0 specs on peut lire :
"Dans le HTML 4 basé sur SGML, il est possible d'omettre la
balise de fin de certains éléments ; en considérant que
l'élément suivant créé une balise de fin implicite.
Cette omission n'est plus autorisée dans le XHTML basé sur
XML. Tous les éléments autres que ceux déclarés dans la DTD
comme EMPTY doivent posséder une balise de fin."
et quelques lignes plus bas :
"les éléments vides doivent toujours avoir une balise de fin
ou la balise de début doit se terminer avec />. Par exemple,
<br/> ou <hr></hr>. Voir les règles de compatibiltés HTML pour
obtenir de l'information sur les moyens d'assurer une
compatibilité antérieure avec les agent utilisateurs HTML 4."

IE ne supporte pas la balise de fin et préfère le />. On voit qu'il a simplement
été bricolé pour être rendu compatible avec le XHTML...

Essaie d'afficher le code de ta page avec
javascript:alert(document.body.innerHTML)
tapé dans la barre d'adresses. L'arbre interprété est intéressant...

--
Y.D.

J'ajoute après quelques minutes de lecture, ceci trouvé toujours
dans les specs XHTML 1.0 (Appendice C. Règles de Compatilité
HTML) :

C.2 Eléments vides
Inclure un espacement avant le / et >de fin des éléments vides,
par exemple <br />, <hr /> et <img src="karen.jpg" alt="Karen" />.
Utilisez également une syntaxe minale pour les éléments vides, par
exemple <br />, comme syntaxe alternative de <br></br> qui est
autorisé par XML, car *cela donne des résultats inattendus dans
certains agents utilisateurs*.

No comment.

--
Y.D.

Depuis quand une balise </input> est-elle un élément ?

Surtout depuis quand un nom de balise peut-il commencer par / !

Bien évidemment, pour confirmer, j'ai rajouté du texte entre les balises
d'ouverture et de fermeture de l'élément input. Avec NS7, même résultat,
tandis qu'avec IE6 cela me rajoute un n½ud texte entre l'élément "INPUT"
et l'« élément "/INPUT" »...

Voilà ce que c'est de jouer avec des interdits !

La DTD HTML 4.xx précise :
<!ELEMENT INPUT - O EMPTY>

Bon, ça y est, j'ai honte. ;-)

Il y avait ça dans le code que j'ai récupéré, et bien sûr je n'ai pas
vérifié la syntaxe. Et je ne peux même pas le passer au validateur
puisque c'est une application qui tourne derrière un pare-feu.

Essaie d'afficher le code de ta page avec
javascript:alert(document.body.innerHTML)
tapé dans la barre d'adresses. L'arbre interprété est intéressant...

Vu. Pour ceux que cela intéresse, voici une page montrant *mon* bug.
http://www.miakinen.net/tmp/bizarre

--
Olivier Miakinen
Non, monsieur le juge, je vous le jure : jamais je n'ai cité
Bruxelles dans ma signature.

Pour ceux que cela intéresse, voici une page montrant *mon* bug.
http://www.miakinen.net/tmp/bizarre

Cela me fait de la peine à dire, mais après tests avec IE6, Firefox1.0
et Opera7.54, le seul navigateur qui pour l'affichage du innerHTML du
2e alert donne un résultat XHTML correct et joliment indenté n'est pas
Firefox mais Opera...

Quand à la validation, j'utilise en local Tidy qui est bien pratique
pour remettre les balises tout en minuscules, ajouter le doctype
kivabien, fermer les balises XHTML (voir http://tidy.sourceforge.net/).

--
Y.D.

YD nous a dit le 10/12/2004 15:11:

Pour ceux que cela intéresse, voici une page montrant *mon* bug.
http://www.miakinen.net/tmp/bizarre

Cela me fait de la peine à dire, mais après tests avec IE6, Firefox1.0
et Opera7.54, le seul navigateur qui pour l'affichage du innerHTML du
2e alert donne un résultat XHTML correct et joliment indenté n'est pas
Firefox mais Opera...

Peux-tu détailler ?
Car sur la page qu'a indiqué Olivier, le doctype utilisé est celui du
HTML 4.01 strict.
Je viens de tester avec Opera 7.50 et 7.60p4 et il met des slashes à la
fin des balises <input>, affiche les balises en majuscules et la valeur
de l'attribut action est incorrecte (elle est incorrecte également en la
récupérant via getAttribute() ou par l'attribut JS 'action').

--
Bobe (Aurélien Maille)
http://webnaute.net

"la vie d'un geek est un combat perpétuel contre l'imperfection"

YD nous a dit le 10/12/2004 15:11:

Pour ceux que cela intéresse, voici une page montrant *mon* bug.
http://www.miakinen.net/tmp/bizarre

Cela me fait de la peine à dire, mais après tests avec IE6, Firefox1.0
et Opera7.54, le seul navigateur qui pour l'affichage du innerHTML du
2e alert donne un résultat XHTML correct et joliment indenté n'est pas
Firefox mais Opera...

Peux-tu détailler ?

Volontiers.

Car sur la page qu'a indiqué Olivier, le doctype utilisé est celui du
HTML 4.01 strict.

Le résultat donné par document.body.innerHTML est la représentation de
l'arbre du document tel qu'il est "en mémoire" du navigateur au moment
où on le demande. C'est le contenu instantané du document. Ce qui est bien
différent du source (on y voit notamment les modifications apportées par
scripting). Le doctype n'y joue plus un grand rôle. Il l'a joué au moment du
parsing de la page, pour la construction du document. Ce que l'on voit là
c'est comment le navigateur a construit le document. Visiblement Opera le
fait nativement en fermant les éléments vides façon XML...

Je viens de tester avec Opera 7.50 et 7.60p4 et il met des slashes à la
fin des balises <input>, affiche les balises en majuscules et la valeur
de l'attribut action est incorrecte (elle est incorrecte également en la
récupérant via getAttribute() ou par l'attribut JS 'action').

Tiens j'avais pas fait attention à la casse... Non conforme à la DTD. Les
valeurs d'attributs aussi (CHECKED="true") et l'indentation est celle du
source : Opera conserve intégralement les espaces... Pour action, on voit
l'URL de la page en cours suivie d'un #, non ? Opera reconstruit l'URL
entière, je ne vois pas le problème : IE et Mozilla vont la calculer au
moment du submit ?

--
Y.D.