innerHTML fait ce qu'il lui plait du code

**_Michel** · 13/08/2012, 23h10

Bonsoir,
lorsque j'exécute le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
<html><head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
 
</head><body>
<div id="file_1"></div>
 
<script type="text/javascript">
	document.getElementById('file_1').innerHTML = '</li><li>\n';
</script>
 
</body></html>

sur firefox, j'obtiens celui-là :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
<html><head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
 
</head><body>
<div id="file_1"><li>
</li></div>
 
<script type="text/javascript">
	document.getElementById('file_1').innerHTML = '</li><li>\n';
</script>
 
</body></html>

Il m'a donc allègrement changé l'ordre des balises <li>, </li> et du retour chariot.
Le comportement normal de innerHTML ne devrait-il pas être de copier la chaîne dans le code html de la page, sans se préoccuper du sens?
Y a-t-il une fonction qui ne se pas toutes ces questions?

Merci d'avance et bonne soirée.

**_Michel** · 13/08/2012, 23h56

En fait il faut que le code soit bien balisé pour que ça marche correctement. Il est peut-être possible de se débrouiller avec innerText. Mais il semble que ces deux fonctions soient le mal.
Je vais donc me débrouiller avec le DOM, qui semble beaucoup plus propre.

**SpaceFrog** · 14/08/2012, 09h55

certains constructeurs de DOM ne créent les balises que si ils trouvent balise fermante.
Ainsi
Ton "</li><li>" ne va créer qu'une balise li.

Avec innerText, le code html ne sera pas interprété mais inséré entant que texte simple, ainsi le code html sera visible.

inneHTML et innerText ne sont pas le mal, pour innerHTML comme tu l'as découvert, ils doit avoir un code html correctement syntaxé et il faut juste faire attention qu le code html soit intégralement compris par le constructeur DOM.
Pour le innerText il n'insère que du texte.

Passer par le DOM permet en effet de s'assurer de la création intégrale de l'objet qui sera donc ensuite intégralement reconnu avec toutes ses propriétés par le DOM.

**sekaijin** · 17/08/2012, 12h43

encore une fois le document HTML (DOM) n'est pas le code HTML qui sert à le générer.

le DOM est le résultat de l'INTERPRETATION du source HTML.

Il s'agit d'une INTERPRETATION. pas d'un copier coler ou quoi que se soit d'autre.

ce n'est pas parce que dans le monde informatique on a mal traduit le mot anglais interpréter qu'il ne s'agita d'un INTERPRETE (et non un interpreteur).

un interprète interprète. il essait donc de comprendre ce que dit la source pour produire une interprétation.

J'espère avoir suffisament martelé le mot.

donc dans le dom il n'y a pas de retour à la ligne de balise </li> ou <li> il n'y a que des Elements et des TextNodes
le code HTML que l'on peut voir dans les débuggueur et autre outils ne sont pas le code HTML du DOM
c'est le résultat de la sérialisation du DOM. Une sérialisation est une représentation sous forme de série de code donnant une représentation de l'objet sérialisé permettant une traduction dans le sens inverse.

Il s'agit donc d'une REPRESENTATION il ne s'agit pas du DOM. pour information le code HTML d'un DOM HTML5 est définit dans la norme comme la sérialisation du DOM c'est le DOM qui est normalisé pas le code source HTML5

encore une fois lorsque vous fournissez un code source HTML à un navigateur et que vous inspecté le DOM les oppération suivantes on lieu
Chargement du code source par le navigateur (visible généralement dans "afficher la source" dans le navigateur)
Interpretation du code
Creation d'un DOM
Serialisation du DOM en code HTML

Chaque étape et source d'erreur et d'approximation.
une erreur dans le flux de la source peut l'intérompre (le document sera partiellement chargé)
une erreur dans le code source html peut donner lieu à une adaptation (le navigateur ajoute ce qui manque, retire ce qu'il a en trop, ou déplace un élément) ou à une erreur (Syntax error)
une erreur peut se produire lors de la creation d'un élément (par exemple une erreur d'allocation memoire)
une erreur peut sur venir à la serialisation le DOM (etant extensible) peut contenir des élément non sérialisables ils sont soit ignorés soit provoque une erreur.

et tout cela dépends de la machine de l'os et du moteur de rendu du navigateur.

il est facile de comprendre qu'avec tout ça ce qu'on met en entrée n'a que peut de chance d'être exactement ce qu'on a en sortie.

le moteur de rendu ne fait jamais ce qu'il VEUT il fait toujours ce qu'il PEUT.

après tout ça on peut ce dire quelle m#rd@ on peut pas travailler avec ça.

je répondrais que si on s'obstine à écrire du code non conforme au B.A.BA. oui on ne peut pas travailler avec.
mais si on respecte à minima les normes du DOM (pas du HTML) alors il n'y a aucun problème à travailler avec.

j'ai bien dit du DOM as du HTML
HTML accept

Code html :

Sélectionner tout - Visualiser dans une fenêtre à part

<table><tr><td>1</td></tr></table>

la norme W3C du DOM ne l'accepte pas le TBody est OBLIGATOIRE.
donc si on ne veux pas d'embrouille avec les navigateur il sufit de le mettre systématiquement.

Je dirais donc lisez la norme du DOM relisez la nore du DOM lisez la norme sur la sérialisation du DOM Lisez la norme de base du XML et vous saurez coder proprement du HTML

A+JYT

**thelvin** · 17/08/2012, 13h12

De toute façon, c'est débile de vouloir fermer une balise avant de l'ouvrir, et je vois mal comment on peut espérer le faire avec le DOM. (J'admets qu'avec innerHTML, même si ça ne fait évidemment rien de cohérent, au moins il était possible de l'écrire.)

innerHTML fait ce qu'il lui plait du code

JavaScript

Discussions similaires

Partager

Partager