document.write() et innerHTML interdit ?

**kernelfailure** · 18/08/2009, 14h22

Salut,

Ca fait un petit moment que mon œil est attiré par des commentaires conseillant à certains de ne pas utiliser document.write() ou innerHTML...

J'ai demandé ce qui motivait ce genre de conseil, mais je n'en sais pas plus pour le moment.

Alors je cherche encore, car pour ce que j'en sais : Cette méthode et cette propriété fonctionnent très bien, et rien ne justifie un tel rejet.

A ce jour, la seule chose qui semble corroborer ce désire de ne "plus" les utiliser semble venir d'ici : Avoid document.write() and innerHTML().

Où un mauvais exemple (Si mauvais que ça ne fonctionnera pas) est donné, avec paragraphe et liste invalides :

Code :

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

1
2
3
4
5
function fillContent() {
	document.write("<h1>Welcome to my site</h1>");
	document.write("<p>Lorem ipsum dolor sit amet");
	document.menu.innerHTML = "<ul><li><a href="foo.html">foo</a>";
}

Puis il est suggèré d'utiliser le code ci-dessous pour produire (?!?) le même résultat, tout en étant valide

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
function fillContent() {
	// parentelem is a specified element in the DOM
	var header = document.createElement("h1");
	header.insertText("Welcome to my site");
	var para = document.createElement("p");
	para.insertText("Lorem ipsum dolor sit amet");
	var list = document.createElement("ul");
	itemone = document.createElement("li");
	itemonelink = document.createElement("a");
	itemonelink.setAttribute("href","foo.html");
	itemonelink.insertText("foo");
	list.appendChild(itemone);
	parentelem.appendChild(header);
	parentelem.appendChild(para);
	parentelem.appendChild(list);
}

Bref ! Soyons clair dans ce genre de recommandations :
l'utilisation de document.write() et innerHTML doit être soumis à la condition de bien former son document.
C'est à dire qu'il soit validé par DOM.

N.B. : Si vous êtes convaincu que la préconisation donnée fait exactement la même chose que le mauvais exemple donné par le W3C, je pense que même l'utilisation de DOM ne viendra pas à votre secours

Alors, est-ce la seule motivation pour inciter à ne pas utiliser document.write() et innerHTML ?
Si c'est la seule, il n'y a vraiment pas de quoi torpiller cette méthode et cette propriété. Sinon, autant ne pas conseiller d'écrire de page HTML et de tout faire par DOM.

**nod__** · 18/08/2009, 14h45

"rien ne justifie un tel rejet." bah si, après on est d'accord ou pas mais il y quelques arguments objectifs.

document.write y'a pas d'excuses. Le comportement est chelou, il induit en erreur en plus d'etre casse-cou pour le navigateur.

innerHTML faut pas faire le boulet avec, et la bonne forme du contenu ajouté n'est pas suffisant pour une bonne utilisation (bien que ça soit nécessaire). Pour ce qui est des performances y'a même pas de débat, l'un et l'autre ont leurs utilisations.

innerHTML pour le travail de bourrin : rajouter 200 élements bien complexes à un noeud, vider un noeud de tous ses enfants.

Le DOM pour le travail en finesse. insérer un noeud avant un autre, après un autre, déplacer un élement dans l'arbre, cloner un autre etc.

c'est pas tout noir et blanc non plus. Le document que tu donnes en lien parle d'accessibilité. Ils te disent que c'est pas bon dans ce cadre là hé bien ce n'est pas bon dans ce cadre là. Dans un autre le problème est différent.

**kernelfailure** · 18/08/2009, 15h58

Envoyé par nod__

document.write y'a pas d'excuses. Le comportement est chelou, il induit en erreur en plus d'etre casse-cou pour le navigateur.

Les seuls trucs chelou que j'ai pu voire avec un document.write(), c'est ce que voulait faire le programmeur.
La plus part de ceux-là oublient tout simplement qu'ils travaillent dans un document... Composé ou en composition.

Pour le travail "en finesse" ou "à la bourrin", c'est plutôt lié à la manière de coder et à son appréciation qu'à l'utilisation de couche applicative particulière.

Envoyé par nod__

c'est pas tout noir et blanc non plus. Le document que tu donnes en lien parle d'accessibilité. Ils te disent que c'est pas bon dans ce cadre là hé bien ce n'est pas bon dans ce cadre là. Dans un autre le problème est différent.

Ce document est pour le moment le seul que j'ai trouvé où il est préconisé d'utiliser DOM plutôt que document.write() et innerHTML de manière argumenté.
La raison qui est ici invoquée (Que je trouve particulièrement faiblarde) est : Quand on connait pas la norme HTML, on utilise DOM.
Et pourquoi pas utiliser Word tant qu'on y est ? Ben, wouai ! Ca fait des docs normées en HTML.

**RomainVALERI** · 18/08/2009, 16h26

Envoyé par kernelfailure

Quand on connait pas la norme HTML, on utilise DOM.

L'accès, la modification, et la récupération (par un submit notamment) d'éléments ajoutés dans la page avec document.write ou Element.innerHTML posent de nombreux problèmes, fais quelques recherches sur ces forums pour t'en convaincre : les "victimes" ne sont, contrairement à tes propos, pas toujours de malheureux noobs illettrés infouttus de coder trois balises dans une page.

Une fois sur deux, quand quelqu'un vient écrire un post (exemple) disant "au secours mon formulaire ne renvoie pas les bonnes valeurs !" ... on lui demande de nous montrer son code : tiens tiens que vois-je ainsi sous mes yeux éclatés

: l'insertion dynamique d'un select sans utiliser les fonctions DOM... étonnant, non ? ^^

**kernelfailure** · 19/08/2009, 13h15

Envoyé par RomainVALERI

...les "victimes" ne sont, contrairement à tes propos, pas toujours de malheureux noobs illettrés infouttus de coder trois balises dans une page.

Jamais je n'aurais osé affirmer ça. Tout le monde fait et à droit de faire des erreurs. Noobs ou plus

Envoyé par RomainVALERI

Une fois sur deux, quand quelqu'un vient écrire un post (exemple) disant "au secours mon formulaire ne renvoie pas les bonnes valeurs !" ... on lui demande de nous montrer son code : tiens tiens que vois-je ainsi sous mes yeux éclatés

: l'insertion dynamique d'un select sans utiliser les fonctions DOM... étonnant, non ? ^^

Jette un oeil sur le site de la RATP, tu verra une belle aberration fonctionner...

Pour ton exemple, ce qui me surprend, c'est qu'à aucun des derniers ".append" n'apparait de "onchange" sur les nouveaux select...
Par ailleurs, je trouve risqué de provoquer une éventuelle collision d'id.

**Bovino** · 19/08/2009, 13h38

Jette un oeil sur le site de la RATP, tu verra une belle aberration fonctionner...

Ca n'a strictement rien à voir... RomainVALERI te parle de l'insertion dynamique de champs de formulaire en vue d'une soumission vers le serveur, toi tu nous montres une autocomplétion dont le seul but est de remplir un champ déjà existant...
Pour info, IE accepte très difficilement l'attribution dynamique de l'attribut name et jamais avec innerHTML, donc si tu dois ajouter un champ à ton formulaire, il ne faut pas passer par innerHTML (car pas de name, pas d'envoi).

**kernelfailure** · 19/08/2009, 14h46

Ok.
Donc, si je comprends bien :

Je viens de tester ceci, qui fonctionne sous IE7 et FF... (Il s'agit bien de faire ça ?)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
 <HEAD>
  <TITLE> New Document </TITLE>
  <SCRIPT LANGUAGE="JavaScript">
  <!--
	function grpUpdate(liquid) {
		var id = document.getElementById("Grp");
		var what = '';
		switch(liquid) {
			case 'cafe':
				what = "<select name='liquidCafe' onchange='alert(this.options[this.options.selectedIndex].value)'><option value=''>-- Faites votre choix --</option><option value='sucre'>Cafe sucre</option><option value='sans sucre'>Cafe sans sucre</option></select>";
				break;
			case 'cacao':
				what = "<select name='liquidCacao' onchange='alert(this.options[this.options.selectedIndex].value)'><option value=''>-- Faites votre choix --</option><option value='sucre'>Cacao sucre</option><option value='sans sucre'>Cacao sans sucre</option></select>";
				break;
		}
		alert( document.getElementById("forma").length );
		id.innerHTML = what;
		alert( document.getElementById("forma").length );
		return true;
	}
  //-->
  </SCRIPT>
 </HEAD>
 
 <BODY>
  <FORM id="forma" METHOD=POST ACTION="">
	Cafe : <INPUT TYPE="radio" NAME="radioGrp" value="cafe" onclick="return grpUpdate(this.value)">&nbsp;&nbsp;&nbsp;
	Cacao : <INPUT TYPE="radio" NAME="radioGrp" value="cacao" onclick="return grpUpdate(this.value)">
	<div id="Grp"></div>
	<INPUT TYPE="submit" name="liquid" value="Envoyer">
  </FORM>
 </BODY>
</HTML>
<?php
if( isset($_POST['liquid']) ) {
        foreach($_POST as $k => $v) {
                echo $k." = ".$v."<br />";
        }
}
?>

P.S. : Doit-on dans ce cas considérer encore une merdouille sur IE6 ?

**RomainVALERI** · 19/08/2009, 15h36

Envoyé par kernelfailure

P.S. : Doit-on dans ce cas considérer encore une merdouille sur IE6 ?

Vu les stats d'utilisation...
>>> à mon avis oui, surtout dans un contexte pro (paradoxalement...

)...
Mais par contre on est effectivement en droit d'espérer que les utilisateurs se décident à lacher enfin cette épave radioactive d'IE6 qui a supplicié et terni l'âme de tant de développeurs candides et insouciants

Quoi qu'il en soit, il me semble que je continuerai pour ma part, quand le contexte y est propice, a utiliser les fonctions DOM de préférence, notamment pour le bénéfice de maintenabilité et de lisibilité que cela me semble apporter.

(Remarque : en dehors de ça, je ne suis pas un "ayatollah" du DOM et j'utilise parfois innerHTML (mais pas document.write n'abusons pas ) dans quelques cas de figure...)

**kernelfailure** · 19/08/2009, 17h44

Ca marche aussi sous Safari, par contre c'est dans les choux avec IE5 pour Mac... (En même temps, il y a peu de chose qui marche sous IE5 Mac

)

Si quelqu'un a un IE6 sous la main et peut faire le test

Je cherche à comprendre pourquoi recommander de se passer de document.write() ou innerHTML dans tous les cas, surtout là où ils peuvent apporter une solution simple à mettre en oeuvre.

A l'inverse, DOM se complique lorsque, par exemple, on ne peut créer certains attributs sous tel navigateur et que par conséquent, il faut passer par un codage direct de l'attribut sur l'objet... Et parfois, c'est l'inverse.
C'est loin d'être crossbrowser aussi ce DOM...

Tiens, mieux. Il y a un thread où on apprend que DOM génère un tag non valide pour l'élément IMG

A vérifier, mais si c'est pareil avec les INPUT, BR, HR, ... J'ai plus tout en tête (Tous les "<!ELEMENT foo - O EMPTY>") ... Ca jette un pavé sur les objets DOM tout de même, non ?

C'est pas facile tout ça, mais qu'est-ce qu'on se marre

**nod__** · 19/08/2009, 18h04

<img/> rien a voir. le tag est valide, l'auteur du sujet ne comprends juste pas le contexte.

et on recommende pas de se passer de ces trucs pour compliquer, on les utilise là ou c'est pertinent et y'a pas mort d'homme. Encore une fois tout dépend du contexte.

**SpaceFrog** · 19/08/2009, 19h00

Utiliser le DOM est la seul façon sûre de ne pas avoir de surprises ...
document.write est un fossile dépassé
et innerHTML ne peut se justifier que pour insérer du texte...

Maintenant si tu veux utiliser innerHTML et document.write à la pelle on est sûr de te revoir ...

**kernelfailure** · 19/08/2009, 21h41

Ah oui ? Avec DOM pas de surprise ?

Voici un fait :
Je viens d'adapter l'exemple tout bête du dessus en DOM pure.
Résultat : Marche sous FF et Safari

IE7 : Dans les choux pour ce qui est des évènements (Que j'ai bêtement, comme un noob, passés comme des Attributs).
IE5 Mac : Rien à faire. Cette fois-ci les select-box ne montent même pas à l'écran. Avec la méthode précédente, ils montent mais ne sont pas intégré dans le formulaire au moment du POST.

Je ne peux pas affirmer mieux que ce que je viens de prouver :
Avec DOM, tout ne se passe pas aussi bien que vous voulez bien l'affirmer.
Etrangement, j'ai un meilleur taux de réussite avec innerHTML (Grâce à IE7).

FF et Safari répondent indifféremment dans chacun des cas.

Je vous met le code, peut-être que j'ai fait des trucs bizarres, je ne suis sur de rien, mettez moi le nez dessus au cas où :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
 <HEAD>
  <TITLE> New Document </TITLE>
  <SCRIPT LANGUAGE="JavaScript">
  <!--
	var withDOM = true;
 
	function grpUpdate(liquid) {
		var id = document.getElementById("Grp");
 
		withDOM = document.getElementById("avecDOM");
		withDOM = withDOM.options[withDOM.options.selectedIndex].value == '1'?true:false;
 
		if( !withDOM ) {
			var what = '';
			switch(liquid) {
				case 'cafe':
					what = "<select name='liquidCafe' onchange='alert(this.options[this.options.selectedIndex].value)'><option value=''>-- Faites votre choix sans DOM --</option><option value='sucre'>Cafe sucre</option><option value='sans sucre'>Cafe sans sucre</option></select>";
					break;
				case 'cacao':
					what = "<select name='liquidCacao' onchange='alert(this.options[this.options.selectedIndex].value)'><option value=''>-- Faites votre choix sans DOM --</option><option value='sucre'>Cacao sucre</option><option value='sans sucre'>Cacao sans sucre</option></select>";
					break;
			}
			alert( document.getElementById("forma").length );
			id.innerHTML = what;
			alert( document.getElementById("forma").length );
 
		} else {
 
			while(id.hasChildNodes()) { id.removeChild(id.lastChild) }
 
			var sel = document.createElement('select');
			sel.setAttributeNode(document.createAttribute('name'));
			var arr = [];
			switch(liquid) {
				case 'cafe':
					sel.setAttribute('name','liquidCafe');
					arr.push(['sucre','Cafe sucre']);
					arr.push(['sans sucre','Cafe sans sucre']);
					break;
				case 'cacao':
					sel.setAttribute('name','liquidCacao');
					arr.push(['sucre','Cacao sucre']);
					arr.push(['sans sucre','Cacao sans sucre']);
					break;
			}
			sel.setAttributeNode(document.createAttribute('onchange'));
			sel.setAttribute('onchange','alert(this.options[this.options.selectedIndex].value)');
 
			sel.appendChild(document.createElement('option'));
			sel.lastChild.setAttributeNode(document.createAttribute('value'));
			sel.lastChild.setAttribute('value','');
			sel.lastChild.appendChild(document.createTextNode('-- Faites votre choix avec DOM --'));
 
			for(all in arr) {
				sel.appendChild(document.createElement('option'));
				sel.lastChild.setAttributeNode(document.createAttribute('value'));
				sel.lastChild.setAttribute('value',arr[all][0]);
				sel.lastChild.appendChild(document.createTextNode(arr[all][1]));
			}
 
			id.appendChild(sel);
		}
		return true;
	}
  //-->
  </SCRIPT>
 </HEAD>
 
 <BODY>
  <FORM id="forma" METHOD=POST ACTION="">
		<select id="avecDOM" name="avecDOM"><option value="0" selected>Sans DOM</option><option value="1">Avec DOM</option></select><br /><br />
 
	Cafe : <INPUT TYPE="radio" NAME="radioGrp" value="cafe" onclick="return grpUpdate(this.value)" />&nbsp;&nbsp;&nbsp;
	Cacao : <INPUT TYPE="radio" NAME="radioGrp" value="cacao" onclick="return grpUpdate(this.value)" />
	<div id="Grp"></div>
	<INPUT TYPE="submit" name="liquid" value="Envoyer" />
  </FORM>
 </BODY>
</HTML>
<?
if( isset($_POST['liquid']) ) {
	foreach($_POST as $k => $v) {
		echo $k." = ".$v."<br />";
	}
}
?>

N.B. : je n'ai pas cherché à négocier la gestion des évènements. Le but était ici de porter le innerHTML en DOM pure. Sinon, autant sortir la gestion des évènements pour la totalité, n'est-ce pas ?

De tout ceci, il est tout de même utilede préciser que ce n'est pas DOM qui est en cause, mais son implémentation au saint des différents navigateurs (Enfin, du même qui fait toujours cavalier seul

)

**RomainVALERI** · 19/08/2009, 23h12

Je crois que tu te focalises trop sur la question d'un hypothétique choix technique "tout-innerhtml" VS "tout-DOM", en supposant qui plus est des choix d'implémentation indéfendables...

D'une part (et je ne suis pas le seul ici à l'avoir déjà affirmé plus haut), il faut savoir utiliser innerHTML dans certains contextes, plutot que du appendChild/createTextNode ou disons plus globalement "les fonctions DOM" : pour éviter les quelques irrégularités d'implémentation, pour la performance dans certains contextes, etc. (je vous en supplie ne trollons pas sur ce satané sujet de la performance, c'était si intéressant jusqu'à maintenant

)

Mais il y a aussi ceci : quand on utilise les fonctions DOM en respectant également certains autres bons principes de développement web, on se garantit, avant toute utilisation de ces fonctions, de l'implémentation du DOM assurée par le client : ton test sur IE5 Mac n'est pas probant car le problème vient des choix de conception mis en oeuvre : un utilisateur du DOM plus aguerri ou plus rigoureux aurait détecté une implémentation (admettons, je n'ai pas vérifié) partielle de DOM 1, et totalement absente pour DOM 2. Et ça n'aurait donc posé aucun souci car il aurait bien sûr prévu une version "dégradée" de bonne qualité qui n'insulte pas le visiteur, ni ne le bloque dans sa consultation. ^^

Et sinon :

Envoyé par kernelfailure

C'est pas facile tout ça, mais qu'est-ce qu'on se marre

En tout cas : la conjugaison du scepticisme et de la curiosité intellectuelle ont toujours fait avancer le débat, donc quoi qu'il en soit, merci pour ta tenacité pour le moins, heu... tenace

**kernelfailure** · 20/08/2009, 01h22

Envoyé par RomainVALERI

Je crois que tu te focalises trop sur la question d'un hypothétique choix technique "tout-innerhtml" VS "tout-DOM", en supposant qui plus est des choix d'implémentation indéfendables...

Pas exactement. Je souhaites faire relativiser les commentaires qui laissent à penser qu'utiliser DOM résout tous les problèmes.
Moi-même je suis très tenté par son utilisation. Mais, je suis encore trop déçu par la disparité des portages.

Envoyé par RomainVALERI

...
Mais il y a aussi ceci : quand on utilise les fonctions DOM en respectant également certains autres bons principes de développement web, on se garantit, avant toute utilisation de ces fonctions, de l'implémentation du DOM assurée par le client : ton test sur IE5 Mac n'est pas probant car le problème vient des choix de conception mis en oeuvre : un utilisateur du DOM plus aguerri ou plus rigoureux aurait détecté une implémentation (admettons, je n'ai pas vérifié) partielle de DOM 1, et totalement absente pour DOM 2. Et ça n'aurait donc posé aucun souci car il aurait bien sûr prévu une version "dégradée" de bonne qualité qui n'insulte pas le visiteur, ni ne le bloque dans sa consultation. ^^

Oui, bien sur. D'ailleurs en général, une batterie de tests intervient pour tout un tas de choses.
La validation sur IE5 Mac est surtout pour l'amusement (toujours déprimant ce type de test, est de toute manière à proscrire - Comme l'utilisation de ce nav... truc).
Mais là où le test est pertinent, c'est sur IE7, où en DOM pure ça coince.
DOM n'est pas le zorro dans tous les cas, la preuve. Ce qui ne veut pas dire qu'il est à négliger non plus.

Une chose, comme ça me vient à l'esprit sur l'utilisation de document.write() que bon nombre ne veulent pas/plus utiliser et privilégient DOM : L'avantage de cette méthode, c'est qu'elle n'a pas besoin de la validation du document.

J'entends par là, qu'elle permet d'intervenir avant que le document ne soit (normalement... disons : ne devrait être) parsé via DOM. Dans un cas de figure comme celui-là, on peut surtout s'étonner que certaines méthodes DOM soient accessible pendant l'élaboration du doc, non ?
Puisqu'en toute logique, l'utilisation d'un Node ne devrait être possible qu'à partir du moment où le document est valide.

Personnellement, je pense que document.write() a encore de beaux jours devant elle et qu'il faudra revoir votre position quand DOM ne sera accessible que sur un document strictement valide

Et ca reste hyper utile pour le debug des scripts et la construction paramétré du contenu d'un document, d'un script.

**Bovino** · 20/08/2009, 08h06

Pour en revenir à ton exemple de innerHTML, il fonctionne aussi avec IE6

Pour le reste, innerHTML n'est pas une spécification du W3C, donc son avenir est incertain (même si les besoins de rétrocompatibilité le feront bien sûr perdurer), en revanche, on assiste actuellement à une montée en puissance des respects des standards, donc je pense que le DOM va devenir de plus en plus fiable, même pour IE

Ceci dit, il faut effectivement relativiser et c'est en fonction des besoins / contraintes qu'il faut faire les choix des méthodes utilisées...

**kernelfailure** · 20/08/2009, 11h27

Merci pour ce feedback, Bovino.

C'est sur innerHTML n'est pas une spécification. Mais pour une fois, son implémentation est standard sur "la plupart" des navigateurs. C'est à souligner

Bien sur, on peut miser sur une standardisation de DOM (croisons les doigts). Mais ça fait aussi plus de 10 ans que j'espère une "standardisation" de JS

**RomainVALERI** · 20/08/2009, 11h36

Envoyé par kernelfailure

Mais ça fait aussi plus de 10 ans que j'espère une "standardisation" de JS

C'est bien le rôle d'ECMAScript : par contre, on a beau mettre au point tous les standards qu'on veut, en définitive ce sont les éditeurs des navigateurs qui, par leur choix d'implémentation, vont déterminer le contexte dans lequel nous autres devons finalement travailler... ^^

**GBS63** · 22/08/2009, 12h32

hello,

j'utilise beaucoup & souvent innerHTML... notamment dans des applications AJAX,

bien utilisée, je trouve cette méthode très pratique,

après, faire appel aux fonctions DOM que vous citez, ça marche également, mais bon... ya plus de lignes à coder ! ^^

alors tant que le résultat marche avec innerHTML... je ne vois pas d'inconvénients à continuer,

**E.Bzz** · 26/08/2009, 12h17

Envoyé par Bovino

Pour en revenir à ton exemple de innerHTML, il fonctionne aussi avec IE6

Vu que ça n'a pas été clairement dit : non, l'ajout d'éléments dans un form via innerHTML ne fonctionne pas avec IE6 ...
Ce qui est (pour l'instant en tous cas et pour encore quelques temps) une raison suffisante pour ne pas l'utiliser dans ce cas ...
Hors <form>, aucun problème.

A+

**Bovino** · 26/08/2009, 12h26

Envoyé par E.Bzz

Vu que ça n'a pas été clairement dit : non, l'ajout d'éléments dans un form via innerHTML ne fonctionne pas avec IE6 ...
Ce qui est (pour l'instant en tous cas et pour encore quelques temps) une raison suffisante pour ne pas l'utiliser dans ce cas ...
Hors <form>, aucun problème.

A+

Ben si justement...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
 <HEAD>
  <TITLE> New Document </TITLE>
  <SCRIPT LANGUAGE="JavaScript">
  <!--
	function grpUpdate(liquid) {
		var id = document.getElementById("Grp");
		var what = '';
		switch(liquid) {
			case 'cafe':
				what = "<select name='liquidCafe' onchange='alert(this.options[this.options.selectedIndex].value)'><option value=''>-- Faites votre choix --</option><option value='sucre'>Cafe sucre</option><option value='sans sucre'>Cafe sans sucre</option></select>";
				break;
			case 'cacao':
				what = "<select name='liquidCacao' onchange='alert(this.options[this.options.selectedIndex].value)'><option value=''>-- Faites votre choix --</option><option value='sucre'>Cacao sucre</option><option value='sans sucre'>Cacao sans sucre</option></select>";
				break;
		}
		alert( document.getElementById("forma").length );
		id.innerHTML = what;
		alert( document.getElementById("forma").length );
		return true;
	}
  //-->
  </SCRIPT>
 </HEAD>
 
 <BODY>
  <FORM id="forma" METHOD=POST ACTION="">
	Cafe : <INPUT TYPE="radio" NAME="radioGrp" value="cafe" onclick="return grpUpdate(this.value)">&nbsp;&nbsp;&nbsp;
	Cacao : <INPUT TYPE="radio" NAME="radioGrp" value="cacao" onclick="return grpUpdate(this.value)">
	<div id="Grp"></div>
	<INPUT TYPE="submit" name="liquid" value="Envoyer">
  </FORM>
 </BODY>
</HTML>
<?php
if( isset($_POST['liquid']) ) {
        foreach($_POST as $k => $v) {
                echo $k." = ".$v."<br />";
        }
}
?>

Fonctionne correctement avec IE6 (page de test).

document.write() et innerHTML interdit ?

JavaScript

Discussions similaires

Partager

Partager