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ÝANfV61VaIqaNbHeMm4KsVQem1mMTMElT9vyWt-2hJI B7wEdQ2PdH3JSuZPv03VwbaEZn0Xtl9h2CSXwzK5xpkELXCprZTAAvBRWOwcNlZm6lde1gndK 87g_sUXh56YUY0yUkmDNsYMSO1M0oIkYghX4PgD3Op-mkLoztN8aO9EORm20&tc33 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>
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&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>
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ÝANfV61VaIqaNbHeMm4KsVQem1mMTMElT9vyWt-2hJI B7wEdQ2PdH3JSuZPv03VwbaEZn0Xtl9h2CSXwzK5xpkELXCprZTAAvBRWOwcNlZm6lde1gndK 87g_sUXh56YUY0yUkmDNsYMSO1M0oIkYghX4PgD3Op-mkLoztN8aO9EORm20&tc33 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.
J'y suis.
J'y suis.
J'y suis.
J'y suis.
J'y suis.
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.
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_railElement">
<div class="ajax__slider_h_handle" style="overflow: hidden;
position: absolute; left: 140px;">
<img
src="WebResource.axd?dÝANfV61VaIqaNbHeMm4KsVQem1mMTMElT9vyWt-2hJIB7wEdQ2PdH3JSuZPv03VwbaEZn0Xtl9h2CSXwzK5xpkELXCprZTAAvBRWOwcNlZm6lde1gndK87g_sUXh56YUY0yUkmDNsYMSO1M0oIkYghX4PgD3Op-mkLoztN8aO9EORm20&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>
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.
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_railElement">
<div class="ajax__slider_h_handle" style="overflow: hidden;
position: absolute; left: 140px;">
<img
src="WebResource.axd?dÝANfV61VaIqaNbHeMm4KsVQem1mMTMElT9vyWt-2hJIB7wEdQ2PdH3JSuZPv03VwbaEZn0Xtl9h2CSXwzK5xpkELXCprZTAAvBRWOwcNlZm6lde1gndK87g_sUXh56YUY0yUkmDNsYMSO1M0oIkYghX4PgD3Op-mkLoztN8aO9EORm20&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>
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.
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_railElement">
<div class="ajax__slider_h_handle" style="overflow: hidden;
position: absolute; left: 140px;">
<img
src="WebResource.axd?dÝANfV61VaIqaNbHeMm4KsVQem1mMTMElT9vyWt-2hJIB7wEdQ2PdH3JSuZPv03VwbaEZn0Xtl9h2CSXwzK5xpkELXCprZTAAvBRWOwcNlZm6lde1gndK87g_sUXh56YUY0yUkmDNsYMSO1M0oIkYghX4PgD3Op-mkLoztN8aO9EORm20&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>
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'Ajax
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 commande.
Sur une machine très lente qui doit jouer à la fois les rôles de serveur
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élai
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),
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.
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'Ajax
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 commande.
Sur une machine très lente qui doit jouer à la fois les rôles de serveur
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élai
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),
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.
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'Ajax
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 commande.
Sur une machine très lente qui doit jouer à la fois les rôles de serveur
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élai
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),
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.
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,
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]
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.
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,
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]
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.
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,
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]
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.
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.
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.
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.
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.
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 pa r 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 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 ?!
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 ? ...)
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 pui s à 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 saisi e, 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 ?
Et quel affichage ?
celui de mon iPhone ? de mon NetBook 7" ? mon 27" ? les 8 à 900px de
large auxquels je force mes navigateurs ?
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 ?)
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.
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 pa r 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 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 ?!
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 ? ...)
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 pui s à 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 saisi e, 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 ?
Et quel affichage ?
celui de mon iPhone ? de mon NetBook 7" ? mon 27" ? les 8 à 900px de
large auxquels je force mes navigateurs ?
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 ?)
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.
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 pa r 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 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 ?!
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 ? ...)
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 pui s à 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 saisi e, 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 ?
Et quel affichage ?
celui de mon iPhone ? de mon NetBook 7" ? mon 27" ? les 8 à 900px de
large auxquels je force mes navigateurs ?
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 ?)
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)
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é)
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)
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é)
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)
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é)
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,
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,
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,