Modifier une TextBox

Gloops a écrit le 27/09/2014 07:46 :

Bonjour tout le monde,

Quelqu'un a-t-il une idée de pourquoi ce code fonctionne bien sous IE ,
mais pas sous Firefox ?

Depuis un input type="image" situé dans une cellule d'un tableau, j e
veux diminuer de 10 la valeur dans un input type="text" situé dans la
troisième cellule de la même ligne du tableau.

Firefox affiche "debut", et puis c'est tout.

Je n'ai pas vu de réserve quant à Firefox dans la doc de parentNode ni
celle de childNodes.

onclick="javascript:alert('debut');var
txb=this.parentNode.parentNode.childNodes[2].childNodes[1];alert(txb. id);txb.value=txb.value
- 10;"

A toutes fins utiles voici le code de la cellule cible :

<td id="td3">

<div class="ajax__slider_h_rail" tabindex="-1"
id="ctl00_ContentPlaceHolder1_AffichePlat1_SliderExtender1_railElemen t">
<div class="ajax__slider_h_handle" style="overflow: hidden;
position: absolute; left: 140px;">
<img
src="WebResource.axd?d=dDANfV61VaIqaNbHeMm4KsVQem1mMTMElT9vyWt-2hJI B7wEdQ2PdH3JSuZPv03VwbaEZn0Xtl9h2CSXwzK5xpkELXCprZTAAvBRWOwcNlZm6lde1gndK 87g_sUXh56YUY0yUkmDNsYMSO1M0oIkYghX4PgD3Op-mkLoztN8aO9EORm20&amp;t=6333 98816400000000"
id="ctl00_ContentPlaceHolder1_AffichePlat1_SliderExtender1_handleImag e">
</div>
</div>
<input style="display: none;"
name="ctl00$ContentPlaceHolder1$AffichePlat1$txbCuissonLineaire"
value="100"
onchange="javascript:setTimeout('__doPostBack('ctl00$ContentPlaceHol der1$AffichePlat1$txbCuissonLineaire','')',
0)" onkeypress="if (WebForm_TextBoxKeyHandler(event) == false) re turn
false;" id="ctl00_ContentPlaceHolder1_AffichePlat1_txbCuissonLineaire "
type="text">

</td>

J'y suis. L'espace qui se trouve au début de la cellule est compté so us
Firefox (pas sous IE) comme son élément n° 0, ce qui décale la su ite, et
qui fait donc que txbCuissonLineaire est l'élément n° 2 alors que s ous
IE c'est l'élément n° 1.

Pour avoir le même script sous IE et Firefox, j'ai remplacé le
childNodes[1] de la fin du chemin par getElementsByTagName (à la casse
près car je le cite de mémoire) comme ceci :
getElementsByTagName("input")[0]

et ça marche.

Alors après si il y a de la prose à raconter pour comprendre pourquoi
l'espace de début est compté comme un élément sous Firefox et pas sous
IE, ça j'ignore.

Gloops a écrit le 27/09/2014 14:03 :

J'y suis.

Maintenant que le script fonctionne, ça me laisse un peu de temps pour
m'intéresser à des messages de la console Firefox dont l'intérêt
n'apparaissait pas central pour déboguer.

La console attire mon attention sur la notion de reflow.

Les anglophones pourront en savoir plus là :
https://developers.google.com/speed/articles/reflow

Pour résumer, le navigateur doit recalculer la taille et la position
d'éléments de la page pour qu'ils tiennent compte les uns des autres. La
durée du reflow s'accroît du fait de la superposition d'éléments, et de
l'usage de chemins relatifs dans le DOM.

Justement, ma page utilise ces deux éléments, puisque :
1/ la zone de saisie texte est masquée par un contrôle Slider de l'Aj ax
Control Toolkit, afin de faciliter la saisie en visualisant la valeur
numérique au prorata du segment minimum/maximum
2/ pour le support clavier je recours à l'évaluation relative de la
position d'un élément, par rapport à celui qui déclenche une comm ande.

Sur une machine très lente qui doit jouer à la fois les rôles de se rveur
et de machine cliente, j'obtiens le repositionnement du slider sur son
rail en presque une seconde, un peu moins si la manÂœuvre est renouvelé e
plusieurs fois. Plusieurs pressions successives ne donnent lieu au déla i
qu'une fois, le curseur étant observé à sa position initiale puis à sa
position finale.

J'ai donc l'impression d'avoir fait une concession nécessaire pour
obtenir un meilleur confort de saisie.

Au demeurant, j'ai placé, pour le mettre au point, un contrôle
d'affichage d'article (en fait de plat pour un restaurant), je vais
probablement découvrir d'autres points intéressants maintenant que la
question va être de placer plusieurs exemplaires de ce contrôle sur l a
page, puisque c'est à ce prix que je propose un choix au client final.

Gloops a écrit le 27/09/2014 14:03 :

J'y suis.

Maintenant que le script fonctionne, ça me laisse un peu de temps pour
m'intéresser à des messages de la console Firefox dont l'intérêt
n'apparaissait pas central pour déboguer.

La console attire mon attention sur la notion de reflow.

Les anglophones pourront en savoir plus là :
https://developers.google.com/speed/articles/reflow

Pour résumer, le navigateur doit recalculer la taille et la position
d'éléments de la page pour qu'ils tiennent compte les uns des autres. La
durée du reflow s'accroît du fait de la superposition d'éléments, et de
l'usage de chemins relatifs dans le DOM.

Justement, ma page utilise ces deux éléments, puisque :
1/ la zone de saisie texte est masquée par un contrôle Slider de l'Aj ax
Control Toolkit, afin de faciliter la saisie en visualisant la valeur
numérique au prorata du segment minimum/maximum
2/ pour le support clavier je recours à l'évaluation relative de la
position (dans l'arbre DOM) d'un élément, par rapport à celui qui
déclenche une commande.

Sur une machine très lente qui doit jouer à la fois les rôles de se rveur
et de machine cliente, j'obtiens le repositionnement du slider sur son
rail en presque une seconde, un peu moins si la manÂœuvre est renouvelé e
plusieurs fois. Plusieurs pressions successives ne donnent lieu au déla i
qu'une fois, le curseur étant observé à sa position initiale puis à sa
position finale.

J'ai donc l'impression d'avoir fait une concession nécessaire pour
obtenir un meilleur confort de saisie.

Au demeurant, j'ai placé, pour le mettre au point, un contrôle
d'affichage d'article (en fait de plat pour un restaurant), je vais
probablement découvrir d'autres points intéressants maintenant que la
question va être de placer plusieurs exemplaires de ce contrôle sur l a
page, puisque c'est à ce prix que je propose un choix au client final.


(supersedes pour corrections)

Le 27/09/14 07:46, Gloops a écrit :

Bonjour tout le monde,

Quelqu'un a-t-il une idée de pourquoi ce code fonctionne bien sous IE,
mais pas sous Firefox ?

Depuis un input type="image" situé dans une cellule d'un tableau, je
veux diminuer de 10 la valeur dans un input type="text" situé dans la
troisième cellule de la même ligne du tableau.

Firefox affiche "debut", et puis c'est tout.

c'est quand même curiousss qu'un nombre s'écrive 'début' !!

Je n'ai pas vu de réserve quant à Firefox dans la doc de parentNode ni
celle de childNodes.

qu'est-ce qu'on a à faire de ces complications-DOM-nodes alors qu'on a à
dispo le JS simplissime propre aux formulaires ?
(avec son avantage quant à la vitesse, à ce que j'ai cru comprendre)

onclick="javascript:alert('debut');var
txb=this.parentNode.parentNode.childNodes[2].childNodes[1];alert(txb.id);txb.value=txb.value
- 10;"

A toutes fins utiles voici le code de la cellule cible :

Ha? Paske tout ce verbiage ne représente qu'un petit td ?

<td id="td3">

<div class="ajax__slider_h_rail" tabindex="-1"
id="ctl00_ContentPlaceHolder1_AffichePlat1_SliderExtender1_railElement">
<div class="ajax__slider_h_handle" style="overflow: hidden;
position: absolute; left: 140px;">
<img
src="WebResource.axd?dÝANfV61VaIqaNbHeMm4KsVQem1mMTMElT9vyWt-2hJIB7wEdQ2PdH3JSuZPv03VwbaEZn0Xtl9h2CSXwzK5xpkELXCprZTAAvBRWOwcNlZm6lde1gndK87g_sUXh56YUY0yUkmDNsYMSO1M0oIkYghX4PgD3Op-mkLoztN8aO9EORm20&amp;tc3398816400000000"
id="ctl00_ContentPlaceHolder1_AffichePlat1_SliderExtender1_handleImage">
</div>
</div>
<input style="display: none;"
name="ctl00$ContentPlaceHolder1$AffichePlat1$txbCuissonLineaire"
value="100"
onchange="javascript:setTimeout('__doPostBack('ctl00$ContentPlaceHolder1$AffichePlat1$txbCuissonLineaire','')',
0)" onkeypress="if (WebForm_TextBoxKeyHandler(event) == false) return
false;" id="ctl00_ContentPlaceHolder1_AffichePlat1_txbCuissonLineaire"
type="text">

</td>

en très laid JavaScript de nos grand' mères :

<img src="1.jpg" alt="bouton"
onclick="ctl00$ContentPlaceHolder1$AffichePlat1$txbCuissonLineaire.value
= 'blabla';" />

L'image est entre les 2 balises "form" du formulaire.

Quelle était la question ?
Car enfin ... on aimerait connaitre le contenu du texte à passer à
ctl00$ContentPlaceHolder1$AffichePlat1$txbCuissonLineaire
histoire de voir à voir

Ha? c'est une simple opération ?
Mézalors il faut bien se souvenir que la valeur d'un input/text est du
"texte" et non pas un "nombre" même si elle est '23'

et donc,
maybe :

<img src="1.jpg" alt="bouton"
onclick="var c =
ctl00$ContentPlaceHolder1$AffichePlat1$txbCuissonLineaire; c.value -=
10;" />

ou:

<img src="1.jpg" alt="bouton"
onclick="var c =
ctl00$ContentPlaceHolder1$AffichePlat1$txbCuissonLineaire; c.value =
c.value*1-10;" />

En délayé (plus propre ?) :
var c =
this.form.elements['ctl00$ContentPlaceHolder1$AffichePlat1$txbCuissonLineaire'];



Cordialement,
--
Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8

Le 27/09/14 15:49, Gloops a écrit :

Gloops a écrit le 27/09/2014 14:03 :

J'y suis.

Maintenant que le script fonctionne, ça me laisse un peu de temps pour
m'intéresser à des messages de la console Firefox dont l'intérêt
n'apparaissait pas central pour déboguer.

La console attire mon attention sur la notion de reflow.

Les anglophones pourront en savoir plus là :
https://developers.google.com/speed/articles/reflow

Pas lu l'article mais ... si tout est dimensionné d'avance (ou stylé
proprement *) il ne doit pas il y avoir beaucoup de reflow, ou, en tous
cas, pas beaucoup de délai perceptible à la réorganisation de l'affichage.

Sauf,
sauf,
sauf,
à utiliser des tables pour la mise en forme

surtout,
surtout,
avec IE qui les digère très mal
(pas trop essperimenté les versions >7)


*
On style tout pour l'objet invisible, et il passe ensuite en visible par JS
Pareil pour display 'none'/'block'
Ne concerne le "dynamisme" (changement progressif). Encore que ... avec
le HTML.5 ?
Mébon ... pas de table, pas de table et pas de table !!!
(pour un resto ... pas idéal ! ;-) )

Pour résumer, le navigateur doit recalculer la taille et la position
d'éléments de la page pour qu'ils tiennent compte les uns des autres. La
durée du reflow s'accroît du fait de la superposition d'éléments,et de
l'usage de chemins relatifs dans le DOM.

d'où l’intérêt de se servir d'une fonction qui sera réutilisée pour
chaque groupe concerné par le phénomène dont une tentative d'explication
est donnée ci-après.

Justement, ma page utilise ces deux éléments, puisque :
1/ la zone de saisie texte est masquée par un contrôle Slider de l'Ajax
Control Toolkit, afin de faciliter la saisie en visualisant la valeur
numérique au prorata du segment minimum/maximum

rhen compris à rhen compris à cette histoire de segmentation
ni de "numérique" pour des plats culinaires ?!

2/ pour le support clavier je recours à l'évaluation relative de la
position d'un élément, par rapport à celui qui déclenche une commande.

Boudiou !
V'là t'encore pire !
C'est quoi cette histoire de "support clavier" ?
déjà : quoi t'est-ce "support" ?
ensuite, le clavier ?
- celui virtuel des tablettes et phones ?
- celui du Mac ? du PC ?
- de quelles races ces claviers ? (US, PU, ES, FR-CA ? FR-FR ? ...)

Sur une machine très lente qui doit jouer à la fois les rôles de serveur

Le serveur, en local, est immédiat ! (calculs, échanges, toussa)

et de machine cliente, j'obtiens le repositionnement du slider sur son
rail en presque une seconde,

Boudiou !!!!
c'est plus que lent ça là dis donc !
Doit y avoir plein de temporisations JS ou d'effets de styles ?

un peu moins si la manœuvre est renouvelée plusieurs fois.

Y a combien d'aller/retour avec le serveur pour élastiquer cette zone de
saisie ?
(l'Ajaxionnage est-il d'à propos ? réellement ? et si oui, est-il
optimisé ?)

Plusieurs pressions successives ne donnent lieu au délai
qu'une fois, le curseur étant observé à sa position initiale puis à sa
position finale.

??? rien compris
une pression sur "quoi" ?

J'ai donc l'impression d'avoir fait une concession nécessaire pour
obtenir un meilleur confort de saisie.

Je ne comprends pas qu'il faille 1 seconde pour traiter le contenu du
champ de texte (puisque ce n'est fait qu'une fois en fin de saisie).
Ou alors c'est voulu ? Pour des effets smooth d'affichages ?
Au passage je ne vois pas comment est déterminée la fin de la saisie, la
« position finale ».

Au demeurant, j'ai placé, pour le mettre au point, un contrôle
d'affichage d'article (en fait de plat pour un restaurant),

un contrôle d'affichage ?
ou de choix ?

Pour le contrôle d'affichage, je ne vois pas trop comment ça peut
fonctionner.

Et quel affichage ?
celui de mon iPhone ? de mon NetBook 7" ? mon 27" ? les 8 à 900px de
large auxquels je force mes navigateurs ?

probablement découvrir d'autres points intéressants maintenant que la
question va être de placer plusieurs exemplaires de ce contrôle sur la
page, puisque c'est à ce prix que je propose un choix au client final.

C'est au prix du contrôle des clients que tu leur proposes des choix ?
(s'il prend de la salade en entrée, les épinards lui seront refusés au
plat suivant ?)



Cordialement,
--
Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8

Le 27/09/14 14:03, Gloops a écrit :

J'y suis. L'espace qui se trouve au début de la cellule est compté sous
Firefox (pas sous IE) comme son élément n° 0, ce qui décale la suite,

d'où l’intérêt, dès que c'est possible, d'atteindre les machins par
leurs *name* pour les éléments de *form*
(on peut aussi les atteindre par leurs rang dans la collection de ces
éléments)

Pour avoir le même script sous IE et Firefox, j'ai remplacé le
childNodes[1] de la fin du chemin par getElementsByTagName (à la casse
près car je le cite de mémoire) comme ceci :
getElementsByTagName("input")[0]

c'est la méthode la plus simple si on ne connait pas d'avance les noms
des éléments

function diminue(){
var part = this.parentNode; // le parent en franchissant l’écueil du
while(part.tagName != 'TD') part = part.parentNode // node fantôme
var cible = part.getElementsByTagName('INPUT')[0].
cible.value = cible.value*1-10;
}

Alors après si il y a de la prose à raconter pour comprendre pourquoi
l'espace de début est compté comme un élément sous Firefox et pas sous
IE, ça j'ignore.

Ben paske ...
les navigateurs consciencieux se créent ce node (contrairement à cet IE
dissipé)



Cordialement,
--
Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8

Le 27/09/14 14:03, Gloops a écrit :

Alors après si il y a de la prose à raconter pour comprendre pourquoi
l'espace de début est compté comme un élément sous Firefox et pas sous
IE, ça j'ignore.

Je rappelle mes réponses précédentes (23/08/14) et leurs liens

Réponses qui évoquaient déjà ce problème de node invisible.

Cordialement,
--
Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8

SAM a écrit le 30/09/2014 03:23 :

Pas lu l'article mais ... si tout est dimensionné d'avance (ou stylé
proprement *) il ne doit pas il y avoir beaucoup de reflow, ou, en tous
cas, pas beaucoup de délai perceptible à la réorganisation de l'a ffichage.

De ce côté ça a l'air à peu près correct, pour la machine que c 'est.

Sauf,
sauf,
sauf,
à utiliser des tables pour la mise en forme

Là, si je voulais des boutons à gauche et à droite du curseur, la t able
m'évitait des heures et des heures de recherche ...

surtout,
surtout,
avec IE qui les digère très mal
(pas trop essperimenté les versions >7)

Ah, IE6 ... C'est vrai qu'il me sort (depuis le WebBrowser sur les
clients lourds) des erreurs sur certains sites, qui ont répondu d'entré e
ah non je ne vais pas me fatiguer à assurer la compatibilité avec ç a ...
Du coup j'ai ajouté un champ dans la table pour mémoriser pour chaque
site si on autorise les messages de débogage.
Enfin là ce n'est pas le projet dont je parlais au début.

On style tout pour l'objet invisible, et il passe ensuite en visible pa r JS
Pareil pour display 'none'/'block'

Tu veux dire qu'on risque de gagner du temps si je mets une plus grande
largeur à la cellule qui contient le slider et sa textbox ?
Tiens c'est possible, ça ...

Ne concerne le "dynamisme" (changement progressif). Encore que ... avec
le HTML.5 ?

Ah, le HTML 5 ...
ça fait un bout de temps que j'ai repéré qu'il faudra que je passe un
peu de temps là-dessus. Le CSS 3 aussi.

Mébon ... pas de table, pas de table et pas de table !!!
(pour un resto ... pas idéal ! ;-) )

Je vois que Monsieur a de l'humour :)

N'empêche, pour gérer la réservation des tables, il fallait que je crée
... une table dans la base. Je l'ai appelée TableDeRestau, sinon bonj our
les confusions ... Y compris pour le système.

Pour résumer, le navigateur doit recalculer la taille et la position
d'éléments de la page pour qu'ils tiennent compte les uns des autr es. La
durée du reflow s'accroît du fait de la superposition d'élémen ts,et de
l'usage de chemins relatifs dans le DOM.

d'où lÂ’intérêt de se servir d'une fonction qui sera réutilisé e pour
chaque groupe concerné par le phénomène dont une tentative d'expl ication
est donnée ci-après.

Justement, ma page utilise ces deux éléments, puisque :
1/ la zone de saisie texte est masquée par un contrôle Slider de l 'Ajax
Control Toolkit, afin de faciliter la saisie en visualisant la valeur
numérique au prorata du segment minimum/maximum

rhen compris à rhen compris à cette histoire de segmentation
ni de "numérique" pour des plats culinaires ?!

Le plus souvent, quand on commande son plat, on le demande saignant,
moyen ou bien cuit. J'ai appelé ça la cuisson par paliers. Je propose
aussi au restaurateur qu'un plat puisse être proposé avec une cuisson
linéaire, c'est-à-dire que le degré de cuisson demandé par le cli ent va
être exprimé par un nombre. Ce mode de gestion de la cuisson est asso rti
d'un maximum à saisir en même temps que le choix du mode de cuisson. Si
c'est 100, le degré de cuisson choisi par le client sera un pourcentage ,
de la cuisson maximale (quasi carbonisé). Sinon on peut imaginer que ç a
soit un nombre de minutes.

2/ pour le support clavier je recours à l'évaluation relative de l a
position d'un élément, par rapport à celui qui déclenche une c ommande.

Boudiou !
V'là t'encore pire !
C'est quoi cette histoire de "support clavier" ?
déjà : quoi t'est-ce "support" ?
ensuite, le clavier ?
- celui virtuel des tablettes et phones ?
- celui du Mac ? du PC ?
- de quelles races ces claviers ? (US, PU, ES, FR-CA ? FR-FR ? ...)

Moui, ce n'était pas très clair.
Alors donc, le curseur sert à choisir un niveau de cuisson, entre 0 et
le maximum. Avec le curseur c'est facile à choisir à la souris.
Au clavier, comme la zone de saisie est masquée, nada. Alors, j'ai mis
deux boutons avec des scripts. Celui de gauche diminue le degré de
cuisson choisi de 10, et celui de droite l'augmente de 10. Cela jusqu'à
la limite, mais ça c'est le Slider qui le gère.


Bon alors ça ça marche très bien quand le composant est tout seul s ur la
page.

Bien entendu, il s'agit de présenter plusieurs plats. Pour ça sur
ASP.Net on a quelque chose qui s'appelle une DataList. C'est bien, ça
m'affiche mes différents plats, sauf que là la plate-forme bloque les
scripts clients de peur que ça soit des scripts pirates. Il y a une
commande pour les autoriser, mais j'ai dû me planter dessus, j'attends
que quelqu'un me réponde dans le forum adapté.

et de machine cliente, j'obtiens le repositionnement du slider sur son
rail en presque une seconde,

Boudiou !!!!
c'est plus que lent ça là dis donc !
Doit y avoir plein de temporisations JS ou d'effets de styles ?

Hum ... Si tu voyais la machine que c'est tu comprendrais.
Pour charger le navigateur j'attends une minute.

un peu moins si la manÂœuvre est renouvelée plusieurs fois.

Y a combien d'aller/retour avec le serveur pour élastiquer cette zone de
saisie ?
(l'Ajaxionnage est-il d'à propos ? réellement ? et si oui, est-il
optimisé ?)

C'est vrai qu'il faut un aller-retour pour gérer ça, car le slider de
l'AjaxControlToolkit ne gère pas son contenu en local. J'ai mis un
moment à réaliser ça.
Du coup ça va plus vite de déclencher le script plusieurs fois, comme ça
il n'y a qu'un aller-retour pour donner la position finale.

Plusieurs pressions successives ne donnent lieu au délai
qu'une fois, le curseur étant observé à sa position initiale pui s à sa
position finale.

??? rien compris
une pression sur "quoi" ?

Les boutons que j'ai mis pour augmenter ou diminuer la valeur du degré
de cuisson.

J'ai donc l'impression d'avoir fait une concession nécessaire pour
obtenir un meilleur confort de saisie.

Je ne comprends pas qu'il faille 1 seconde pour traiter le contenu du
champ de texte (puisque ce n'est fait qu'une fois en fin de saisie).
Ou alors c'est voulu ? Pour des effets smooth d'affichages ?
Au passage je ne vois pas comment est déterminée la fin de la saisi e, la
« position finale ».

Ce qu'il faut gérer, c'est la position du curseur.
J'ai d'abord cherché à le faire en local, mais ce truc n'a pas de
propriété value. C'est le postback qui le repositionne.

Au demeurant, j'ai placé, pour le mettre au point, un contrôle
d'affichage d'article (en fait de plat pour un restaurant),

un contrôle d'affichage ?
ou de choix ?

En fait j'ai fini par m'apercevoir que c'est un peu plus sophistiqué qu e
ça. J'ai créé une structure avec un plat, un degré de cuisson, un numéro
de variante et une quantité. Le plat est désigné dans cette structu re
par son numéro, et le composant d'affichage affiche le nom, la
description, la photo et les différentes variantes. Il permet aussi de
retourner le numéro de variante sélectionné ainsi que le degré de
cuisson sélectionné.

Maintenant que j'ai su afficher tout ça, il reste à autoriser les
scripts côté client sinon je ne suis pas avancé. Mais ça, ça re lève du
forum ASP.Net.

Et quel affichage ?
celui de mon iPhone ? de mon NetBook 7" ? mon 27" ? les 8 à 900px de
large auxquels je force mes navigateurs ?

Pour le moment j'ai fait attention d'utiliser des div float plutôt que
des tableaux, pour qu'on puisse afficher sur un petit écran. Après, j e
me doute qu'il y aura d'autres points qu'il faudra que j'aborde pour
vraiment assurer la compatibilité avec les téléphones portables.

C'est au prix du contrôle des clients que tu leur proposes des choix ?
(s'il prend de la salade en entrée, les épinards lui seront refusé s au
plat suivant ?)

De la mise en boîte, pas vrai ?
:)

SAM a écrit le 30/09/2014 03:24 :

Le 27/09/14 14:03, Gloops a écrit :

J'y suis. L'espace qui se trouve au début de la cellule est compté sous
Firefox (pas sous IE) comme son élément n° 0, ce qui décale la suite,

d'où lÂ’intérêt, dès que c'est possible, d'atteindre les machi ns par
leurs *name* pour les éléments de *form*
(on peut aussi les atteindre par leurs rang dans la collection de ces
éléments)

C'est ce que j'ai fini par faire. Avec seulement un composant sur la
page, ça marche très bien.
Il restera à tester avec plusieurs composants sur la page, puisque pour
le moment les scripts clients sont bloqués.

Alors après si il y a de la prose à raconter pour comprendre pourq uoi
l'espace de début est compté comme un élément sous Firefox et pas sous
IE, ça j'ignore.

Ben paske ...
les navigateurs consciencieux se créent ce node (contrairement à ce t IE
dissipé)

C'est cohérent avec la réputation de IE d'être un peu fantaisiste a vec
l'implémentation des standards. Je serais bien en peine de développer plus.

Il sert à quoi ce nÂœud au fait ?

SAM a écrit le 30/09/2014 03:29 :

Le 27/09/14 14:03, Gloops a écrit :

Alors après si il y a de la prose à raconter pour comprendre pourq uoi
l'espace de début est compté comme un élément sous Firefox et pas sous
IE, ça j'ignore.

Je rappelle mes réponses précédentes (23/08/14) et leurs liens

Réponses qui évoquaient déjà ce problème de node invisible.

Cordialement,

Ah, oui, c'est à cette occasion que j'ai appris que dans la page
ASP.Net, il faut se méfier du sens de "Visible". Visible="false"
signifie absent de la page sur le navigateur client. Donc, logiquement,
inaccessible aux scripts clients.