Avec Gecko, absolument aucun problème. Le DOMParser renvoi bien un XMLDocument, avec des beaux nœuds DOMElement, et on peut attacher des event listeners sur les éléments, créer des événements, les propager etc.. Bref, ça fait ce que ça doit faire. Le bonheur.

Avec Opera, on arrive à s'en sortir, il a une implémentation native correcte comme dans Gecko. Il y a juste des bizarreries, comme sur getElementByTagName. Par contre, il est le seul à implémenter xml:id, ce dont on a besoin.

Avec IE, il n'y a pas d'objet DOMParser. On se dit, c'est un peu normal, dans la mesure où on sait que IE et XML, ça fait deux. Mais il y a quand même un activeX similaire. Qui fonctionne... En fait, non, je n'appelle pas ça fonctionner. Le problème est que ce parser est complètement à la ramasse. Déjà il ne tient pas compte des DTD, ne connait même pas le namespace "xml", et j'en passe. Le pire est qu'il retourne des objets ActiveX, et non des objets Javascript. Ainsi il est impossible de toucher au prototype, de redéfinir des méthodes, ce qui serait utile pour compléter ou corriger l'implémentation. Parce que bien sûr, l'implémentation du DOM dans ce truc est complètement "fucké" comme dirait mon collègue. Par exemple, il n'y a même pas de localName sur les éléments, getElementsByTagName est buggé, et d'une manière général, le support des namespaces sur cette implémentation est archi buggé et incomplète. Un comble pour un parser XML. (Pu***, mais faites disparaître ce navigateur de merde !!! Et que ses développeurs soient maudis sur 15 générations ! )

Conclusion : le parser XML de IE est juste inutilisable. Mon collègue Olivier (Maître es-javascript) a donc réimplémenté un DOMParser XML et un pseudo DOM pour IE, avec juste ce dont on a besoin. Super lourd. Mais on n'a pas trop le choix.

Avec webkit, c'est un peu mieux. Ou pas. Il a un DOMParser, qui nous ressort bien un arbre DOM à peu prés correct. Mais là où ça coince : pas de stack d'événements sur l'implémentation. On ne peut pas propager des événements. Et là on se dit, sur webkit, ils ont fumé la moquette. Parce que Webkit est censé supporter XHTML, et donc les événements dans XHTML. Or, XHTML, c'est du XML. Mais si en XML, il n'y a pas de support d'événements, ça veut dire que l'implémentation de XHTML ne repose pas sur celle de XML, ou que l'implémentation des événements n'est pas faite sur les classes de base XML, mais sur les classes XHTML qui en hérite. Enfin bref, une raison dans le genre. Je ne suis pas allé voir le code de webkit. Mais c'est en tout cas pas logique du tout.

Toujours est-il qu'on ne peut pas propager d'événement. On s'est dit, on va modifier le prototype des objets DOM retournés par le DOMParser de webkit, et on va implémenter une stack d'events. Las, les constructeurs XMLDocument et Node ne sont apparemment pas appelés lorsque le document est construit , et du coup, on ne peut pas appliquer la stack sur les prototypes parce qu'on ne peut pas avoir de variables privées "instance".

Conclusion : avec webkit, c'est aussi le cauchemar. L'unique solution que l'on voit, c'est de refaire là aussi un parser XML et implémentation DOM (celle qu'on a fait pour IE n'est pas totalement réutilisable, n'est pas complète, et repose en partie sur l'active X parser de IE). Mais ce serait d'une connerie sans nom. Du très grand n'importe quoi. C'est totalement désespérant.

Si il y a un spécialiste webkit dans le coin qui aurait un tuyau à nous filer pour nous éviter de réinventer la roue...