Précision, je viens de vérifier une nouvelle fois. Alors sur FF3, les </tr> y sont mais pas sur IE7.
C'est quoi encore ce truc ?????
En effet, en XHTML c'est une erreur grave (par contre en HTML non, c'est pas obligatoire). Mais comme le site est en XHTML 1.1 j'ai intérêt à corriger ça.
Sur ce genre d'erreur, la majorité des navigateurs sont assez permissif en effet (et corrige le code, notamment Firefox, le code est faux si tu demandes l'intégralité du code, mais si tu demande une partie il va te donner ce que lui voit vraiment). Il semblerait qu'ils ne considèrent pas cela comme une faute grave. De plus c'est affiché correctement. En fait, j'ai l'impression que pour IE il n'y a pas de rapport en l'affichage et le DOM (bref, l'affichage passe, mais le DOM dernière ça doit être le bordel).
J'ai corrigé, à tester.
Je valide la correction, mais l'erreur javascript reste présente.
Dommage, ce n'était pas pour cette raison.
Comme pour le [lien="/Bugs/Tracker.html?bug=24"]bug 24[/lien], il s'agit d'un bug de IE qui est en fait incapable de traité le innerHTML. Sauf que j'avoue que pour le 24 je peux arriver à m'en sortir sans trop de problème. Pour celui là... C'est beaucoup, beaucoup plus compliqué vu l'hétérogénéité des éléments à rentrer dans la <tr> de la table (span, select, option, input, etc. à écrire entièrement en DOM de façon dynamique... autant dire que ça va prendre un temps fou) . Je vais probablement être obligé de générer un tableau en <span> ou <div> sinon je ne vais pas m'en sortir.
IE c'est que des emmerdes J'espère que ce genre de connerie sera corrigé dans IE8, parce que la reconstruction de DOM via innerHTML est supporté par tous les navigateurs sauf lui. C'est pas ce qu'il y a de mieux techniquement, mais ça permet d'éviter d'avoir à écrire 200 lignes de code là où l'on peut en mettre qu'une seule.