Yo'

Donc voila, je vois un peu partout sur le forum "innerHTML c'est mal!", "Utilise les DOMs plutôt!", ...

Mais là viens la question essentielle à mes yeux... Pourquoi?

J'ai donc mené ma petite enquête et je ne trouve pas vraiment de chose qui y répondent concrètement..

Citation : http://www.developer-x.com/content/innerhtml/

Arguments for and against
For

* Convinient and fast.
* Easy to use and understand.
* Works in general situations where some factors are unknown.
* Great for writing data to a node, This could take along time with the DOM.
* In situations where you need innerHTML, nothing else will do
* innerHTML is significantly faster than the DOM in Gecko and IE (See Aaron's and Stephen's comments below).

Against

* It is NOT a W3C DOM standard. It won't likely become one either.
* The DOM is more powerful.
* Its name contains HTML, although it could be used for SGML/XML documents.
* It is lazy and can produce unstructured, lazy code.
* It can lead new developers away from learning about text nodes.
* Code will become hard to port to XML apps and won't be future proof.
* Should the browser be parsing HTML strings and creating nodes?!
* innerHTML can mean structural data inside the behavioural element of your app.
* innerHTML is very buggy (to say the least) in the Gecko browsers.

Donc voila, j'ai trouvé ça. Mais je ne vois pas en quoi il est mal..
Quand je fais du javascript (J'utilise du javascript en masse, je ne fais que des micro applications web en fait) tout ce que j'espère, c'est que:
1. Se soit le plus rapide possible
2. Que se soit compatible au maximum

Donc voila, je ne comprend vraiment pas en quoi innerHTML c'est mal

Eclairez ma lamterne

Edit: setTimeout & json: Cf. page 2

bah c'est clair que pour changer le contenu d'une div c'est ce qu'il y a de mieux...
après quand tu veux remplacer les balises d'un certain type par un autre non...
exemple:

<div id="truk1">
<div id="truk2">
1
</div>
</div>

pour changer le contenu de la div, il est évident que

document.getElementById('truk2').innerHTML='2';

suffit.

par contre si tu veux remplacer la div par un span,

document.getElementById('truk1').innerHTML='<span id="truk2">1</span>';

et exactement ce qu'il ne faut pas faire.

il faudrait :
-pointer l'élément (truk=document.getElementById('truk2'));
-en créer un autre dans le parent (truk.parent);
-mettre les attributs et le contenu dans des variables;
-supprimer l'ancien élément;
-remettre les attributs et le contenu depuis les variables;

sinon, l'élément n'existera pas vraiment..
tu pourras y accéder, mais je ne crois pas que tu puisses l'avoir avec document.getElementById etc.

bref le innerHTML pour les contenu des balises n'en contenant pas d'autre;
le DOM pour le reste.

L'usage du DOM a pour principal avantage de réduire considérablement le nombre d'id dans le code. Par contre, quand il s'agit de remplir un noeud, je pense que cela importe peu. Surtout une question de "coder propre" [qui est rarement équivalent à "coder facile" ]

innerHTML c'est pas mal. C'est juste que le DOM ça pue.

Non mais franchement, c'est quoi ces noms à ralonge? j'ai meme plus le courage d'écrire le code pour choper un element par son id alors que c'est la putain de base de l'interraction JS/HTML. depuis quand il faut écrire un roman pour ajouter un noeud?

Moi mon problème c'est le DOM. j'aime pas.

Après standardisé machin, pas "futur proof" mais mdr, non mais il a vu la rapidité de developpement des navigateurs? IE l'implémente pas = pas utilisable. Et je dis rien de la rapidité des specs…

'fin bref, y'a rien de mal à bien utiliser innerHTML.

Ouais enfin "coder propre" c'est différent de "rédiger propre" (voir ma pique sur le roman plus haut).

@Xavier: Les id sont tout à fait reconnu. J'utilise l'innterHTML beaucoup de cette façon car je fais notamment un MMORPG online et donc il y a apparition des caractères, des maps, etc..

@Elias: Mais il y a t-il une utilité à réduire le nombre d'id? Personnellement je travail beaucoup avec les id (J'arrive parfois à plus de 200 éléments avec id dans ma page, voir plus) et ça ne me dérange pas.

@Nod_: document.getElementById(), c'est pas très long non plus ;p Au pire $() =)
"Il n'y a pas de mal a Bien utiliser" => Que signifie le Bien? Ce dont parlait Xavier? Si oui en quoi est-ce "mal" utiliser que de le faire?

Personnellement, je n'aime pas trop multiplier les id, ça limite le risque d'en avoir deux identiques par erreur, ou d'arriver à devoir inventer des noms pas possibles est très obscures pour trouver un id différent pour chaque élément
Mais sinon, l'avantage principal du DOM, c'est de pouvoir faire des fonctions javascript beaucoup plus génériques, sans avoir à modifier le code HTML pour rajouter des id lorsque l'on veut utiliser cette fonction (ou encore mettre des id en dur dans la fonction, qui la rendent impossible à utiliser sur plusieurs éléments d'une même page).

Je t'avouerais ne pas avoir très bien compris ^.^'

En quoi le DOM est différent de innerHTML sur "Modifier le code HTML" ? Les deux crée des éléments HTML donc modifie le code, non?

Les noeuds que tu créés en les ajoutant dynamiquement dans l'arbre DOM, tu peux ensuite les manipuler en javascript sans avoir besoin de les repérer à nouveau. Par contre, les noeuds insérés avec innerHTML, tu dois leur mettre un id et les repérer ensuite si tu veux les manipuler.
Par exemple, si tu insères à l'aide d'innerHTML "<div>ceci est une div</div>", et que tu veux ensuite manipuler cette div, tu dois soit la repérer par après en parcourant l'arbre DOM, soit la repérer en lui collant un id. Par contre, si tu l'as insérée à l'aide des fonctions DOM, tu peux la manipuler directement.
Conséquence au niveau des fonctions génériques : si tu lui avais collé un id pour la repérer ensuite, tu ne peux pas en créer une deuxième avec la même fonction, ou alors tu ajoutes un système pour générer un nouvel id à chaque fois, totalement inutile si tu passes par les fonctions de parcours de l'arbre DOM.

Mwè..
Je pense que je vais encore resté sous innerHTML

+1 Elias

Met du html mal formaté dans ton innerHTML… attends 200 à 400 ms… bravo tu as niqué ta mise en page \o/ (pas toujours, mais c'est possible)

Je vois pas pourquoi je mettrais de l'html mal formaté

C'est comme si je mettais des fausses syntaxes dans le javascript, ça n'a aucun sens

Te sous estime pas, l'humain est très fort pour faire des erreurs à la con (je suis témoin).

ouai mais, si je fais une erreur, c'est comme en JS, j'aurais juste a corriger.

Je dirais même alors que innerHTML est mieux, comme ça tu repères direct tes erreurs

Edit: Je suis sur que Nesquik nous fait un roman, depuis le temps qu'il ecrit ;o

On va faire simple : innerHTML c'est bien quand tu veux simplement ajouter du texte dans une balise, pour le reste je te conseille le DOM pour ses divers avantages :

- Sa rapidité d'exécution (et non pas d'écriture )
- Sa capacité à ajouter une balise dans une autre sans pour autant effacer le contenu existant
- Pour ajouter des styles CSS c'est bien plus clair que tout écrire dans un attribut style.

Et y'en a d'autres mais là je vois que ça.

Concernant le fait de repérer tes erreurs plus facilement tu te trompes, car si tu te goures dans le DOM alors la console JS te le signale, contrairement au innerHTML (car la console n'analyse pas son contenu).

Je vais répondre a chaque point ;o

- Quelle différence entre rapidité d'exécution et écriture?
- innerHTML supporte le += donc pas besoin d'effacer
- Tu peux très bien faire le innerHTML, puis récupérer par l'id et appliquer les styles

Citation : Tiller

- Quelle différence entre rapidité d'exécution et écriture?
Ben quand tu écris ton code en DOM tu mets plus de temps qu'avec un innerHTML .
- innerHTML supporte le += donc pas besoin d'effacer
Ce n'est pas ce que je voulais dire, ça permet cela, d'accord. Mais le DOM permet de placer du code n'importe où sans effacer quoi que ce soit.
- Tu peux très bien faire le innerHTML, puis récupérer par l'id et appliquer les styles
Et un id de plus, un !

Je vais créer une association pour sauvegarder ces pauvres ids que vous voulez faire disparaitre ;D

Quand tu disais rapidité d'écriture, c'était écriture manuscrite (Le code) ou écriture de l'HTML par le javascript ?

Sinon, es-tu certain pour la rapidité d'exécution? D'après ce que j'ai vu sur internet sa semblait pas être vrai..

Si c'est plus rapide. Il faut juste savoir s'en servir. Par exemple mettre machin.innerHTML += "woot"; dans une boucle c'est débile, c'est meme plus long que DOM pour le coup.

Pour le style c'est plus rapide d'ajouer une classe CSS qui contient les style en question que de changer les propriétes à la main, carrément plus rapide.

Je parlais de l'écriture manuscrite, pour écrire le DOM c'est vrai que c'est un peu plus long mais c'est pour la bonne cause.

Concernant la rapidité je n'ai pas de preuve tangible mais soyons logique : d'un côté tu utilises le DOM en disant au navigateur "ajoute-moi cette balise" alors que d'un autre côté tu lui dis avec innerHTML "ajoute-moi ce texte" (car il voit ça comme du texte).

Donc, avec le DOM il va directement savoir quoi ajouter alors que pour innerHTML il devra au préalable analyser le code pour savoir quoi afficher. Enfin ça reste un peu tiré par les cheveux, je le reconnais !

http://www.quirksmode.org/dom/innerhtml.html
Tu cliques sur Testing et tu compares les temps ;o

function inner1()
{
	removeTable();
	var time1 = new Date().getTime();
	var string = '<table><tbody>';
	for (var i=0;i<50;i++)
	{
		string += '<tr>';
		for (var j=0;j<50;j++)
		{
			string += '<td>*</td>';
		}
		string += '</tr>';
	}
	string += '</tbody></table>';
	document.getElementById('writeroot').innerHTML = string;
	var time2 = new Date().getTime();
	doTiming(4,time1,time2);
}

Le problème : c'est pas parceque c'est logique que c'est vrai.

innerHTML nique tout. Le DOM c'est une surcouche au moteur de rendu du navigateur. Ajouter innerHTML tu t'adresse directement au moteur de rendu. DOM tu as un intermédiaire.

T'as pas les bonnes données pour décider.

http://www.quirksmode.org/dom/innerhtml.html grilled

Un truc que j'ai du mal a comprendre nod, tu défends innerHTML ou pas? xD

C'est ambigüe des fois ;o

Edit: Ok tu défends je crois ;o

Il semblerait (je dis bien, il semblerait ) qu'il défende les deux, et qu'il faut savoir jongler entre les deux méthodes.

Citation

Moi mon problème c'est le DOM. j'aime pas.

Pourtant c'était clair

Mais en effet, les 2 sont utiles et necessaires. Faut juste pas faire le blaireau et bien utiliser ce qu'il faut, quand il faut.

Alors je vais formuler un nouveau problème :

C'est quand le bon moment pour le DOM?

Quand tu souhaites ensuite manipuler les éléments que tu insères.

Manipuler mais.. A quel point?

Car si c'est pour l'afficher / masquer une fois par heure~ innerHTML suffit

Quand tu veux insérer une balise comportant des attributs ou des styles. Quand il s'agit d'un simple span avec un id ou une class alors utilise le innerHTML . Ou bien tu peux l'utiliser quand il s'agit de mettre du texte tout simplement.

Bah typiquement un élément dont tu vas ensuite modifier du css (genre des positions ou de l'opacité), ou encore que tu vas supprimer plus tard avec removeChild. En ajoutant l'élément dans l'arbre DOM, tu le conserves dans ton code, par exemple :

document.body.appendChild(infobulle);
//Puis plus tard dans ton code
infobulle.style.display = 'none';

Tu pourrais coller un id à cette infobulle, mais j'ai déjà argumenté sur la non nécessité et les problèmes pouvant découler d'un usage abusif des id à tout va

Le problème sur les ids dont tu parles s'applique ici aussi.

Dans mon élan je peux très bien créer plus tard une variable infobulle sans pensé qu'elle existe deja