du genre, il ne créé pas de noeud DOMText là où il y a juste de simples retour chariots (alors qu'il devrait)
br est le plus casse gueule des éléments (depuis des lustres). One ne sait toujours pas si on doit le considérer comme un contenu brut ou si on doit le considérer comme un bloc. Le W3C n'a pas tranché donc on devrait théoriquement pouvoir lui appliquer des styles et le manipuler via DOM. Tout ceux qui s'y sont essayés se sont pétés la gueule et les transformations/styles sur BR ne sont pris en charge par aucun des navigateurs. De plus BR ne peut pas avoir d'enfants rattachés, pas de contenu et pas d'évennement....
Partant de là IE décide de le considérer non comme un bloc dans un arbre DOM mais comme du contenu pur.
A ce niveau aucune des deux approches ne me parait fausse (br comme noeud ou non), mais personellement je trouve l'approche d'IE plus cohérente. (pourquoi se faire chier à rajouter des noeuds dans l'arbre DOM alors qu'on ne pourra de toute façon rien en faire).
[^] # Re: DOMParser
Posté par Jerome Herman . En réponse au journal if (microsoft()) {kludge;}. Évalué à 2.
br est le plus casse gueule des éléments (depuis des lustres). One ne sait toujours pas si on doit le considérer comme un contenu brut ou si on doit le considérer comme un bloc. Le W3C n'a pas tranché donc on devrait théoriquement pouvoir lui appliquer des styles et le manipuler via DOM. Tout ceux qui s'y sont essayés se sont pétés la gueule et les transformations/styles sur BR ne sont pris en charge par aucun des navigateurs. De plus BR ne peut pas avoir d'enfants rattachés, pas de contenu et pas d'évennement....
Partant de là IE décide de le considérer non comme un bloc dans un arbre DOM mais comme du contenu pur.
A ce niveau aucune des deux approches ne me parait fausse (br comme noeud ou non), mais personellement je trouve l'approche d'IE plus cohérente. (pourquoi se faire chier à rajouter des noeuds dans l'arbre DOM alors qu'on ne pourra de toute façon rien en faire).