Indiquer la position de la souris : javascript ?

Olivier Miakinen

30/04/2008 à 03:14

Le 30/04/2008 01:10, Hugolino a écrit :

Le W3C Validator annonçait 117 erreurs, je suis tombé à 4 après un peu
de nettoyage, mais il y a des trucs que je ne comprends pas, comme le
problème du <div class="change-cursor2crosshair">></div> qui encadre
l'image, div lui même dans un <p></p>, ça dit :
8<-----------8<---------8<----------8<----------8<----------8<----------8<
document type does not allow element "div" here; missing one of
"object", "ins", "del", "map", "button" start-tag .
8<-----------8<---------8<----------8<----------8<----------8<----------8<

Ah, ça c'est parfaitement en charte ici !

Un paragraphe P ne peut contenir que des éléments de type « inline » :
http://www.la-grange.net/w3c/html4.01/struct/text.html#h-9.3.1

Or l'élément DIV est de type « block » :
http://www.la-grange.net/w3c/html4.01/sgml/dtd.html#block

Tu ne peux donc pas mettre un DIV dans un P. Note que le message parlant
des éléments « missing » est de nature à induire en erreur. Il est vrai
que tu peux mettre par exemple un INS dans un P et un DIV dans un INS,
mais en principe on ne devrait pas avoir le droit de mettre un DIV dans
un INS dans un P ! Seul le début de la phrase est vraiment correct (tu
n'as pas le droit de mettre un DIV ici).

Il y aussi <form name="Form1" action="#" onsubmit="return false;"> qui
raconte :
8<-----------8<---------8<----------8<----------8<----------8<----------8<
there is no attribute "name"
You have used the attribute named above in your document, but the
document type you are using does not support that attribute for this
element. This error is often caused by incorrect use of the "Strict"
document type with a document that uses frames (e.g. you must use the
"Transitional" document type to get the "target" attribute), or by using
vendor proprietary extensions such as "marginheight" (this is usually
fixed by using CSS to achieve the desired effect instead).
8<-----------8<---------8<----------8<----------8<----------8<----------8<

Là je ne comprends pas. L'attribut name dans un FORM ne devrait plus
être utilisé (et remplacé par id) mais normalement il est « conservé
pour la rétro-compatibilité » :
http://www.la-grange.net/w3c/html4.01/interact/forms.html#h-17.3

Et deux autres erreurs du même tonneau que je ne comprends pas.

N'hésite pas à venir en parler ici.

Le 30/04/2008 01:10, Hugolino a écrit :

Le W3C Validator annonçait 117 erreurs, je suis tombé à 4 après un peu
de nettoyage, mais il y a des trucs que je ne comprends pas, comme le
problème du <div class="change-cursor2crosshair">></div> qui encadre
l'image, div lui même dans un <p></p>, ça dit :
8<-----------8<---------8<----------8<----------8<----------8<----------8<
document type does not allow element "div" here; missing one of
"object", "ins", "del", "map", "button" start-tag .
8<-----------8<---------8<----------8<----------8<----------8<----------8<

Ah, ça c'est parfaitement en charte ici !

Un paragraphe P ne peut contenir que des éléments de type « inline » :
http://www.la-grange.net/w3c/html4.01/struct/text.html#h-9.3.1

Or l'élément DIV est de type « block » :
http://www.la-grange.net/w3c/html4.01/sgml/dtd.html#block

Tu ne peux donc pas mettre un DIV dans un P. Note que le message parlant
des éléments « missing » est de nature à induire en erreur. Il est vrai
que tu peux mettre par exemple un INS dans un P et un DIV dans un INS,
mais en principe on ne devrait pas avoir le droit de mettre un DIV dans
un INS dans un P ! Seul le début de la phrase est vraiment correct (tu
n'as pas le droit de mettre un DIV ici).

Il y aussi <form name="Form1" action="#" onsubmit="return false;"> qui
raconte :
8<-----------8<---------8<----------8<----------8<----------8<----------8<
there is no attribute "name"
You have used the attribute named above in your document, but the
document type you are using does not support that attribute for this
element. This error is often caused by incorrect use of the "Strict"
document type with a document that uses frames (e.g. you must use the
"Transitional" document type to get the "target" attribute), or by using
vendor proprietary extensions such as "marginheight" (this is usually
fixed by using CSS to achieve the desired effect instead).
8<-----------8<---------8<----------8<----------8<----------8<----------8<

Là je ne comprends pas. L'attribut name dans un FORM ne devrait plus
être utilisé (et remplacé par id) mais normalement il est « conservé
pour la rétro-compatibilité » :
http://www.la-grange.net/w3c/html4.01/interact/forms.html#h-17.3

Et deux autres erreurs du même tonneau que je ne comprends pas.

N'hésite pas à venir en parler ici.

Vous avez filtré cet utilisateur ! Consultez son message

Le 30/04/2008 01:10, Hugolino a écrit :

Le W3C Validator annonçait 117 erreurs, je suis tombé à 4 après un peu
de nettoyage, mais il y a des trucs que je ne comprends pas, comme le
problème du <div class="change-cursor2crosshair">></div> qui encadre
l'image, div lui même dans un <p></p>, ça dit :
8<-----------8<---------8<----------8<----------8<----------8<----------8<
document type does not allow element "div" here; missing one of
"object", "ins", "del", "map", "button" start-tag .
8<-----------8<---------8<----------8<----------8<----------8<----------8<

Ah, ça c'est parfaitement en charte ici !

Un paragraphe P ne peut contenir que des éléments de type « inline » :
http://www.la-grange.net/w3c/html4.01/struct/text.html#h-9.3.1

Or l'élément DIV est de type « block » :
http://www.la-grange.net/w3c/html4.01/sgml/dtd.html#block

Tu ne peux donc pas mettre un DIV dans un P. Note que le message parlant
des éléments « missing » est de nature à induire en erreur. Il est vrai
que tu peux mettre par exemple un INS dans un P et un DIV dans un INS,
mais en principe on ne devrait pas avoir le droit de mettre un DIV dans
un INS dans un P ! Seul le début de la phrase est vraiment correct (tu
n'as pas le droit de mettre un DIV ici).

Il y aussi <form name="Form1" action="#" onsubmit="return false;"> qui
raconte :
8<-----------8<---------8<----------8<----------8<----------8<----------8<
there is no attribute "name"
You have used the attribute named above in your document, but the
document type you are using does not support that attribute for this
element. This error is often caused by incorrect use of the "Strict"
document type with a document that uses frames (e.g. you must use the
"Transitional" document type to get the "target" attribute), or by using
vendor proprietary extensions such as "marginheight" (this is usually
fixed by using CSS to achieve the desired effect instead).
8<-----------8<---------8<----------8<----------8<----------8<----------8<

Là je ne comprends pas. L'attribut name dans un FORM ne devrait plus
être utilisé (et remplacé par id) mais normalement il est « conservé
pour la rétro-compatibilité » :
http://www.la-grange.net/w3c/html4.01/interact/forms.html#h-17.3

Et deux autres erreurs du même tonneau que je ne comprends pas.

N'hésite pas à venir en parler ici.

Olivier Miakinen

30/04/2008 à 03:23

Le 30/04/2008 03:14, Olivier Miakinen a écrit :

problème du <div class="change-cursor2crosshair">></div> qui encadre
l'image, div lui même dans un <p></p>

En donnant l'explication de l'erreur, j'ai oublié de signaler une
correction possible : remplacer le DIV par un SPAN qui, lui, est de
type « inline »

Les inclusions possibles sont résumées ci-dessous :
DIV > DIV > P > SPAN > SPAN > IMG

SAM

30/04/2008 à 10:18

Hugolino a écrit :

Le Tue, 29 Apr 2008 19:45:02 +0200, SAM a écrit:
Et la loupe ?
Où est la loupe ?

C'est quoi ça ?

Une boutade pour dire : et l'image, comment l'agrandir ?
yapa un JS pour le faire ?

Paske là ... je trouve 77px ou 79px et des croutchnes
et ... ha ? ça fait quasi 36mm de toutes façons ? !

J'ai analyser toutes les images cet après midi en me mettant dans la
peau d'un élève et en trçant la trajectoire de la pièce d'après les
coordonnées relevées, et c'est vrai qu'elle est pour le moins cahotique
car il est vraiment difficile de pointer correctement.

Je me demande quand même si la trajectoire n'est pas elle-même un peu
chaotique ?
C'est déjà assez extraordinaire que le truc se meuve rien que par une
très faible tension superficielle, non ?
Bien que ça se voit un peu sur la vidéo, voir (application du DOM) :
<http://cjoint.com/?eEjHEGMLPw>
ou il apparait bien que :
- la trajectoire n'est pas rectiligne
- le mouvement n'est pas continu (accélération, freinage)
- les effets de bord de la tension relative aux parois du récipient
ne sont pas neutre ?
- et l'effet rotation de la Terre ?
- sans parler le la qualité des liquides, de la pièce,
de l'environnement, etc.

à mon idée, bien que non physicien, l'expérience devrait s'arrêter dès
que le truc atteint le centre (ou par là) du cristallisoir.
On voit nettement que ça s'incurve aussitôt après (attirance d'une des
parois ? plus de place pour se mouvoir plus loin? petit défaut du teepol?)

Je referais une vidéo en plus haute résolution pour que l'image soit
plus grande.

ou faire plusieurs vidéos (x expériences)
et cadrer + près de la trajectoire (on n'a pas besoin de voir tout le
récipient).
ou admettre que la physique n'est qu'imprécisions ? :-)

Allez, un autre JS :
<http://cjoint.com/?eEkro2e15X>
(utiliser Fx et attendre patiemment l'affichage)

(Sinon, c'est vraiment que l'affichage du 36,055 n'apporte rien... si ce
n'est que le script n'a pas de bug)

le 36,05 n'est là que pour trouver l'échelle, si la caméra ne bouge pas,
de la relever une fois devrait suffire (c'est vraiment super fastidieux
de recommencer à chaque image) d'autant que tu as le php pour
communiquer l'info de page en page (et totaliser tous les relevés).

Un relevé tous les 0,1 secondes ne suffirait-il pas ?
Un repère sur le milieu arrière de la pièce ne suffirait-il pas ?
(ne serait-ce pas plus précis pour analyser la trajectoire ?)

Le W3C Validator annonçait 117 erreurs, je suis tombé à 4

Bon, Olivier t'a répondu.

Il y aussi <form name="Form1" action="#" onsubmit="return false;"> qui
raconte :

Passe en html au lieu de xhtml qui est très restrictif.
(seuls les éléments des formulaires admettent l'attribut 'name')
Ou supprime le name du form et appelle-le en JS par :
var f = document.forms[0];

Sinon change de doctype,
par exemple :

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

qui permet beaucoup d'à peu près.

Et deux autres erreurs du même tonneau que je ne comprends pas.

Normalement yaka lire :-)
mais ... des fois ce ne sont qu'une seule et même erreur qui cascade
plus loin.

--
sm

Hugolino a écrit :

Le Tue, 29 Apr 2008 19:45:02 +0200, SAM a écrit:

Et la loupe ?
Où est la loupe ?

C'est quoi ça ?

Une boutade pour dire : et l'image, comment l'agrandir ?
yapa un JS pour le faire ?

Paske là ... je trouve 77px ou 79px et des croutchnes
et ... ha ? ça fait quasi 36mm de toutes façons ? !

J'ai analyser toutes les images cet après midi en me mettant dans la
peau d'un élève et en trçant la trajectoire de la pièce d'après les
coordonnées relevées, et c'est vrai qu'elle est pour le moins cahotique
car il est vraiment difficile de pointer correctement.

Je me demande quand même si la trajectoire n'est pas elle-même un peu
chaotique ?
C'est déjà assez extraordinaire que le truc se meuve rien que par une
très faible tension superficielle, non ?
Bien que ça se voit un peu sur la vidéo, voir (application du DOM) :
<http://cjoint.com/?eEjHEGMLPw>
ou il apparait bien que :
- la trajectoire n'est pas rectiligne
- le mouvement n'est pas continu (accélération, freinage)
- les effets de bord de la tension relative aux parois du récipient
ne sont pas neutre ?
- et l'effet rotation de la Terre ?
- sans parler le la qualité des liquides, de la pièce,
de l'environnement, etc.

à mon idée, bien que non physicien, l'expérience devrait s'arrêter dès
que le truc atteint le centre (ou par là) du cristallisoir.
On voit nettement que ça s'incurve aussitôt après (attirance d'une des
parois ? plus de place pour se mouvoir plus loin? petit défaut du teepol?)

Je referais une vidéo en plus haute résolution pour que l'image soit
plus grande.

ou faire plusieurs vidéos (x expériences)
et cadrer + près de la trajectoire (on n'a pas besoin de voir tout le
récipient).
ou admettre que la physique n'est qu'imprécisions ? :-)

Allez, un autre JS :
<http://cjoint.com/?eEkro2e15X>
(utiliser Fx et attendre patiemment l'affichage)

(Sinon, c'est vraiment que l'affichage du 36,055 n'apporte rien... si ce
n'est que le script n'a pas de bug)

le 36,05 n'est là que pour trouver l'échelle, si la caméra ne bouge pas,
de la relever une fois devrait suffire (c'est vraiment super fastidieux
de recommencer à chaque image) d'autant que tu as le php pour
communiquer l'info de page en page (et totaliser tous les relevés).

Un relevé tous les 0,1 secondes ne suffirait-il pas ?
Un repère sur le milieu arrière de la pièce ne suffirait-il pas ?
(ne serait-ce pas plus précis pour analyser la trajectoire ?)

Le W3C Validator annonçait 117 erreurs, je suis tombé à 4

Bon, Olivier t'a répondu.

Il y aussi <form name="Form1" action="#" onsubmit="return false;"> qui
raconte :

Passe en html au lieu de xhtml qui est très restrictif.
(seuls les éléments des formulaires admettent l'attribut 'name')
Ou supprime le name du form et appelle-le en JS par :
var f = document.forms[0];

Sinon change de doctype,
par exemple :

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

qui permet beaucoup d'à peu près.

Et deux autres erreurs du même tonneau que je ne comprends pas.

Normalement yaka lire :-)
mais ... des fois ce ne sont qu'une seule et même erreur qui cascade
plus loin.

--
sm

Vous avez filtré cet utilisateur ! Consultez son message

Hugolino a écrit :

Le Tue, 29 Apr 2008 19:45:02 +0200, SAM a écrit:
Et la loupe ?
Où est la loupe ?

C'est quoi ça ?

Une boutade pour dire : et l'image, comment l'agrandir ?
yapa un JS pour le faire ?

Paske là ... je trouve 77px ou 79px et des croutchnes
et ... ha ? ça fait quasi 36mm de toutes façons ? !

J'ai analyser toutes les images cet après midi en me mettant dans la
peau d'un élève et en trçant la trajectoire de la pièce d'après les
coordonnées relevées, et c'est vrai qu'elle est pour le moins cahotique
car il est vraiment difficile de pointer correctement.

Je me demande quand même si la trajectoire n'est pas elle-même un peu
chaotique ?
C'est déjà assez extraordinaire que le truc se meuve rien que par une
très faible tension superficielle, non ?
Bien que ça se voit un peu sur la vidéo, voir (application du DOM) :
<http://cjoint.com/?eEjHEGMLPw>
ou il apparait bien que :
- la trajectoire n'est pas rectiligne
- le mouvement n'est pas continu (accélération, freinage)
- les effets de bord de la tension relative aux parois du récipient
ne sont pas neutre ?
- et l'effet rotation de la Terre ?
- sans parler le la qualité des liquides, de la pièce,
de l'environnement, etc.

à mon idée, bien que non physicien, l'expérience devrait s'arrêter dès
que le truc atteint le centre (ou par là) du cristallisoir.
On voit nettement que ça s'incurve aussitôt après (attirance d'une des
parois ? plus de place pour se mouvoir plus loin? petit défaut du teepol?)

Je referais une vidéo en plus haute résolution pour que l'image soit
plus grande.

ou faire plusieurs vidéos (x expériences)
et cadrer + près de la trajectoire (on n'a pas besoin de voir tout le
récipient).
ou admettre que la physique n'est qu'imprécisions ? :-)

Allez, un autre JS :
<http://cjoint.com/?eEkro2e15X>
(utiliser Fx et attendre patiemment l'affichage)

(Sinon, c'est vraiment que l'affichage du 36,055 n'apporte rien... si ce
n'est que le script n'a pas de bug)

le 36,05 n'est là que pour trouver l'échelle, si la caméra ne bouge pas,
de la relever une fois devrait suffire (c'est vraiment super fastidieux
de recommencer à chaque image) d'autant que tu as le php pour
communiquer l'info de page en page (et totaliser tous les relevés).

Un relevé tous les 0,1 secondes ne suffirait-il pas ?
Un repère sur le milieu arrière de la pièce ne suffirait-il pas ?
(ne serait-ce pas plus précis pour analyser la trajectoire ?)

Le W3C Validator annonçait 117 erreurs, je suis tombé à 4

Bon, Olivier t'a répondu.

Il y aussi <form name="Form1" action="#" onsubmit="return false;"> qui
raconte :

Passe en html au lieu de xhtml qui est très restrictif.
(seuls les éléments des formulaires admettent l'attribut 'name')
Ou supprime le name du form et appelle-le en JS par :
var f = document.forms[0];

Sinon change de doctype,
par exemple :

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

qui permet beaucoup d'à peu près.

Et deux autres erreurs du même tonneau que je ne comprends pas.

Normalement yaka lire :-)
mais ... des fois ce ne sont qu'une seule et même erreur qui cascade
plus loin.

--
sm

Hugolino

01/05/2008 à 00:23

Le Wed, 30 Apr 2008 10:18:56 +0200, SAM a écrit:

Hugolino a écrit :
Je me demande quand même si la trajectoire n'est pas elle-même un peu
chaotique ?

Elle l'est :)

C'est déjà assez extraordinaire que le truc se meuve rien que par une
très faible tension superficielle, non ?

La valeur moyenne de la force est de 0,1 mN sur les 10 premières images
(avec un écart-type de 0,04 mN), ce qui représente 1/20ème de son poids.

Bien que ça se voit un peu sur la vidéo, voir (application du DOM) :
<http://cjoint.com/?eEjHEGMLPw>

Que veux-tu dire par "application du DOM" ?

ou il apparait bien que :
- la trajectoire n'est pas rectiligne
- le mouvement n'est pas continu (accélération, freinage)
- les effets de bord de la tension relative aux parois du récipient
ne sont pas neutre ?

Oui, oui, et oui.

- et l'effet rotation de la Terre ?

Sur une seconde ? faudra que je vérifie.

à mon idée, bien que non physicien, l'expérience devrait s'arrêter dès
que le truc atteint le centre (ou par là) du cristallisoir.
On voit nettement que ça s'incurve aussitôt après (attirance d'une des
parois ? plus de place pour se mouvoir plus loin? petit défaut du teepol?)

La vitesse chute car la tension superficielle qui tracte la pièce fini
par baisser aussi devant la pièce à cause de la diffusion du liquide
vaisselle dans tout le cristallisoir.
En fait, je pourrais mesurer l'influence de cette vitesse de diffusion
en mesurant l'influence du volume d'eau dans le cristallisoir sur la
trajectoire... On est pas couché :)

De toutes façons, il faut que je refasse la vidéo en mettant la pièce
loin du bord au moment du départ, en cadrant beaucoup plus serré et en
espérant que la pièce veuille bien se positionner dans le sens de la
largeur de l'image pour étaler le déplacement sur 640 px plutôt que 480.

> Je referais une vidéo en plus haute résolution pour que l'image soit
> plus grande.
ou faire plusieurs vidéos (x expériences)

Oui, mais l'expérience ne marche qu'une fois. Après chaque essai, je
dois vider le cristallisoir et le rincer parfaitement, puis le remplir à
nouveau et attendant que l'eau arrête de bouger tout en speedant pour
profiter de la lumière du jour car le 50 Hz des lampes, en plus de faire
des reflets difficiles à gérer interfére avec la vitesse d'obturation de
la webcam.
Je pourrais installer des lampes alimentées en continu et des
diffuseurs, mais faudrait alors que je demande qu'on m'installe un lit
de camp dans le labo :)

et cadrer + près de la trajectoire (on n'a pas besoin de voir tout le
récipient).

Il est clair que la partie intéressante de la trajectoire n'occupe qu'à
peine la moitié de la hauteur, soit environ 200 px. Si elle occupait
plus de 80% de la largeur, je triplerais la définition et donc la
précision des mesures.

ou admettre que la physique n'est qu'imprécisions ? :-)

Tant qu'on arrive à mesurer cette imprécision, pas de problème :)

Allez, un autre JS : <http://cjoint.com/?eEkro2e15X>
(utiliser Fx et attendre patiemment l'affichage)

Ayé, je viens de piger comment obtenir le code source des liens cjoint.
Pour que ça parte dans les archives: clic-droit / Ce cadre / Code source
du cadre.
Je vais regarder ça.

> (Sinon, c'est vraiment que l'affichage du 36,055 n'apporte rien... si ce
> n'est que le script n'a pas de bug)
le 36,05 n'est là que pour trouver l'échelle, si la caméra ne bouge pas,
de la relever une fois devrait suffire (c'est vraiment super fastidieux
de recommencer à chaque image) d'autant que tu as le php pour
communiquer l'info de page en page (et totaliser tous les relevés).

D'une part, la caméra n'était pas assez haute pour éviter un effet de
perspective (je ne voulais pas utiliser de zoom numérque générateur de
bruit) et d'autre part il faut tout de même cliquer sur la pièce pour
relever sa position, donc cliquer deux fois plutôt qu'une...

Un relevé tous les 0,1 secondes ne suffirait-il pas ?

Je préfère avoir trop de données et pouvoir les lisser que pas assez...

Un repère sur le milieu arrière de la pièce ne suffirait-il pas ?
(ne serait-ce pas plus précis pour analyser la trajectoire ?)

Je voulais garder la possibilité de relever les coordonnées des deux
points plutôt que du centre, car ça permet de tenir compte de l'énergie
cinétique de rotation.

De toutes façons, le point n°8 de l'énoncé du TP parlait de critiquer
les mesures et même la vidéo, et le TP a rapidement tourné à
l'apprentissage de l'analyse et du filtrage numérique des données pour
essayer de contrebalancer la pauvre qualité des mesures.

> Le W3C Validator annonçait 117 erreurs, je suis tombé à 4
Bon, Olivier t'a répondu.
> Il y aussi <form name="Form1" action="#" onsubmit="return false;"> qui
> raconte :
Passe en html au lieu de xhtml qui est très restrictif.

Oui, je me demande vraiment pourquoi j'ai choisi le xhtml... j'avais
encore du lire un article qui disait que ça apportait richesse, santé
et permettait le retour de l'être aimé :)

(seuls les éléments des formulaires admettent l'attribut 'name')
Ou supprime le name du form et appelle-le en JS par :
var f = document.forms[0];

OK, je vais faire ça, car changer le doctype de toutes les pages, j'ai
pas le courage.

--

Vous pouvez toujours nous publier votre photo, que je puisse dire si vous
représentez l'esthétique que l'étranger imagine de l'homme français

Vous parlez là à SM/Doom/Chibre. Précisez bien que vous
voulez une photo du visage.

Le Wed, 30 Apr 2008 10:18:56 +0200, SAM a écrit:

Hugolino a écrit :
Je me demande quand même si la trajectoire n'est pas elle-même un peu
chaotique ?

Elle l'est :)

C'est déjà assez extraordinaire que le truc se meuve rien que par une
très faible tension superficielle, non ?

La valeur moyenne de la force est de 0,1 mN sur les 10 premières images
(avec un écart-type de 0,04 mN), ce qui représente 1/20ème de son poids.

Bien que ça se voit un peu sur la vidéo, voir (application du DOM) :
<http://cjoint.com/?eEjHEGMLPw>

Que veux-tu dire par "application du DOM" ?

ou il apparait bien que :
- la trajectoire n'est pas rectiligne
- le mouvement n'est pas continu (accélération, freinage)
- les effets de bord de la tension relative aux parois du récipient
ne sont pas neutre ?

Oui, oui, et oui.

- et l'effet rotation de la Terre ?

Sur une seconde ? faudra que je vérifie.

à mon idée, bien que non physicien, l'expérience devrait s'arrêter dès
que le truc atteint le centre (ou par là) du cristallisoir.
On voit nettement que ça s'incurve aussitôt après (attirance d'une des
parois ? plus de place pour se mouvoir plus loin? petit défaut du teepol?)

La vitesse chute car la tension superficielle qui tracte la pièce fini
par baisser aussi devant la pièce à cause de la diffusion du liquide
vaisselle dans tout le cristallisoir.
En fait, je pourrais mesurer l'influence de cette vitesse de diffusion
en mesurant l'influence du volume d'eau dans le cristallisoir sur la
trajectoire... On est pas couché :)

De toutes façons, il faut que je refasse la vidéo en mettant la pièce
loin du bord au moment du départ, en cadrant beaucoup plus serré et en
espérant que la pièce veuille bien se positionner dans le sens de la
largeur de l'image pour étaler le déplacement sur 640 px plutôt que 480.

> Je referais une vidéo en plus haute résolution pour que l'image soit
> plus grande.
ou faire plusieurs vidéos (x expériences)

Oui, mais l'expérience ne marche qu'une fois. Après chaque essai, je
dois vider le cristallisoir et le rincer parfaitement, puis le remplir à
nouveau et attendant que l'eau arrête de bouger tout en speedant pour
profiter de la lumière du jour car le 50 Hz des lampes, en plus de faire
des reflets difficiles à gérer interfére avec la vitesse d'obturation de
la webcam.
Je pourrais installer des lampes alimentées en continu et des
diffuseurs, mais faudrait alors que je demande qu'on m'installe un lit
de camp dans le labo :)

et cadrer + près de la trajectoire (on n'a pas besoin de voir tout le
récipient).

Il est clair que la partie intéressante de la trajectoire n'occupe qu'à
peine la moitié de la hauteur, soit environ 200 px. Si elle occupait
plus de 80% de la largeur, je triplerais la définition et donc la
précision des mesures.

ou admettre que la physique n'est qu'imprécisions ? :-)

Tant qu'on arrive à mesurer cette imprécision, pas de problème :)

Allez, un autre JS : <http://cjoint.com/?eEkro2e15X>
(utiliser Fx et attendre patiemment l'affichage)

Ayé, je viens de piger comment obtenir le code source des liens cjoint.
Pour que ça parte dans les archives: clic-droit / Ce cadre / Code source
du cadre.
Je vais regarder ça.

> (Sinon, c'est vraiment que l'affichage du 36,055 n'apporte rien... si ce
> n'est que le script n'a pas de bug)
le 36,05 n'est là que pour trouver l'échelle, si la caméra ne bouge pas,
de la relever une fois devrait suffire (c'est vraiment super fastidieux
de recommencer à chaque image) d'autant que tu as le php pour
communiquer l'info de page en page (et totaliser tous les relevés).

D'une part, la caméra n'était pas assez haute pour éviter un effet de
perspective (je ne voulais pas utiliser de zoom numérque générateur de
bruit) et d'autre part il faut tout de même cliquer sur la pièce pour
relever sa position, donc cliquer deux fois plutôt qu'une...

Un relevé tous les 0,1 secondes ne suffirait-il pas ?

Je préfère avoir trop de données et pouvoir les lisser que pas assez...

Un repère sur le milieu arrière de la pièce ne suffirait-il pas ?
(ne serait-ce pas plus précis pour analyser la trajectoire ?)

Je voulais garder la possibilité de relever les coordonnées des deux
points plutôt que du centre, car ça permet de tenir compte de l'énergie
cinétique de rotation.

De toutes façons, le point n°8 de l'énoncé du TP parlait de critiquer
les mesures et même la vidéo, et le TP a rapidement tourné à
l'apprentissage de l'analyse et du filtrage numérique des données pour
essayer de contrebalancer la pauvre qualité des mesures.

> Le W3C Validator annonçait 117 erreurs, je suis tombé à 4
Bon, Olivier t'a répondu.
> Il y aussi <form name="Form1" action="#" onsubmit="return false;"> qui
> raconte :
Passe en html au lieu de xhtml qui est très restrictif.

Oui, je me demande vraiment pourquoi j'ai choisi le xhtml... j'avais
encore du lire un article qui disait que ça apportait richesse, santé
et permettait le retour de l'être aimé :)

(seuls les éléments des formulaires admettent l'attribut 'name')
Ou supprime le name du form et appelle-le en JS par :
var f = document.forms[0];

OK, je vais faire ça, car changer le doctype de toutes les pages, j'ai
pas le courage.

--

Vous pouvez toujours nous publier votre photo, que je puisse dire si vous
représentez l'esthétique que l'étranger imagine de l'homme français

Vous parlez là à SM/Doom/Chibre<tulavu@moncul>. Précisez bien que vous
voulez une photo du visage.

Vous avez filtré cet utilisateur ! Consultez son message

Le Wed, 30 Apr 2008 10:18:56 +0200, SAM a écrit:

Hugolino a écrit :
Je me demande quand même si la trajectoire n'est pas elle-même un peu
chaotique ?

Elle l'est :)

C'est déjà assez extraordinaire que le truc se meuve rien que par une
très faible tension superficielle, non ?

La valeur moyenne de la force est de 0,1 mN sur les 10 premières images
(avec un écart-type de 0,04 mN), ce qui représente 1/20ème de son poids.

Bien que ça se voit un peu sur la vidéo, voir (application du DOM) :
<http://cjoint.com/?eEjHEGMLPw>

Que veux-tu dire par "application du DOM" ?

ou il apparait bien que :
- la trajectoire n'est pas rectiligne
- le mouvement n'est pas continu (accélération, freinage)
- les effets de bord de la tension relative aux parois du récipient
ne sont pas neutre ?

Oui, oui, et oui.

- et l'effet rotation de la Terre ?

Sur une seconde ? faudra que je vérifie.

à mon idée, bien que non physicien, l'expérience devrait s'arrêter dès
que le truc atteint le centre (ou par là) du cristallisoir.
On voit nettement que ça s'incurve aussitôt après (attirance d'une des
parois ? plus de place pour se mouvoir plus loin? petit défaut du teepol?)

La vitesse chute car la tension superficielle qui tracte la pièce fini
par baisser aussi devant la pièce à cause de la diffusion du liquide
vaisselle dans tout le cristallisoir.
En fait, je pourrais mesurer l'influence de cette vitesse de diffusion
en mesurant l'influence du volume d'eau dans le cristallisoir sur la
trajectoire... On est pas couché :)

De toutes façons, il faut que je refasse la vidéo en mettant la pièce
loin du bord au moment du départ, en cadrant beaucoup plus serré et en
espérant que la pièce veuille bien se positionner dans le sens de la
largeur de l'image pour étaler le déplacement sur 640 px plutôt que 480.

> Je referais une vidéo en plus haute résolution pour que l'image soit
> plus grande.
ou faire plusieurs vidéos (x expériences)

Oui, mais l'expérience ne marche qu'une fois. Après chaque essai, je
dois vider le cristallisoir et le rincer parfaitement, puis le remplir à
nouveau et attendant que l'eau arrête de bouger tout en speedant pour
profiter de la lumière du jour car le 50 Hz des lampes, en plus de faire
des reflets difficiles à gérer interfére avec la vitesse d'obturation de
la webcam.
Je pourrais installer des lampes alimentées en continu et des
diffuseurs, mais faudrait alors que je demande qu'on m'installe un lit
de camp dans le labo :)

et cadrer + près de la trajectoire (on n'a pas besoin de voir tout le
récipient).

Il est clair que la partie intéressante de la trajectoire n'occupe qu'à
peine la moitié de la hauteur, soit environ 200 px. Si elle occupait
plus de 80% de la largeur, je triplerais la définition et donc la
précision des mesures.

ou admettre que la physique n'est qu'imprécisions ? :-)

Tant qu'on arrive à mesurer cette imprécision, pas de problème :)

Allez, un autre JS : <http://cjoint.com/?eEkro2e15X>
(utiliser Fx et attendre patiemment l'affichage)

Ayé, je viens de piger comment obtenir le code source des liens cjoint.
Pour que ça parte dans les archives: clic-droit / Ce cadre / Code source
du cadre.
Je vais regarder ça.

> (Sinon, c'est vraiment que l'affichage du 36,055 n'apporte rien... si ce
> n'est que le script n'a pas de bug)
le 36,05 n'est là que pour trouver l'échelle, si la caméra ne bouge pas,
de la relever une fois devrait suffire (c'est vraiment super fastidieux
de recommencer à chaque image) d'autant que tu as le php pour
communiquer l'info de page en page (et totaliser tous les relevés).

D'une part, la caméra n'était pas assez haute pour éviter un effet de
perspective (je ne voulais pas utiliser de zoom numérque générateur de
bruit) et d'autre part il faut tout de même cliquer sur la pièce pour
relever sa position, donc cliquer deux fois plutôt qu'une...

Un relevé tous les 0,1 secondes ne suffirait-il pas ?

Je préfère avoir trop de données et pouvoir les lisser que pas assez...

Un repère sur le milieu arrière de la pièce ne suffirait-il pas ?
(ne serait-ce pas plus précis pour analyser la trajectoire ?)

Je voulais garder la possibilité de relever les coordonnées des deux
points plutôt que du centre, car ça permet de tenir compte de l'énergie
cinétique de rotation.

De toutes façons, le point n°8 de l'énoncé du TP parlait de critiquer
les mesures et même la vidéo, et le TP a rapidement tourné à
l'apprentissage de l'analyse et du filtrage numérique des données pour
essayer de contrebalancer la pauvre qualité des mesures.

> Le W3C Validator annonçait 117 erreurs, je suis tombé à 4
Bon, Olivier t'a répondu.
> Il y aussi <form name="Form1" action="#" onsubmit="return false;"> qui
> raconte :
Passe en html au lieu de xhtml qui est très restrictif.

Oui, je me demande vraiment pourquoi j'ai choisi le xhtml... j'avais
encore du lire un article qui disait que ça apportait richesse, santé
et permettait le retour de l'être aimé :)

(seuls les éléments des formulaires admettent l'attribut 'name')
Ou supprime le name du form et appelle-le en JS par :
var f = document.forms[0];

OK, je vais faire ça, car changer le doctype de toutes les pages, j'ai
pas le courage.

--

Vous pouvez toujours nous publier votre photo, que je puisse dire si vous
représentez l'esthétique que l'étranger imagine de l'homme français

Vous parlez là à SM/Doom/Chibre. Précisez bien que vous
voulez une photo du visage.

Hugolino

01/05/2008 à 00:49

Le Wed, 30 Apr 2008 03:14:49 +0200, Olivier Miakinen a écrit:

Le 30/04/2008 01:10, Hugolino a écrit :
>
> Le W3C Validator annonçait 117 erreurs, je suis tombé à 4 après un peu
> de nettoyage, mais il y a des trucs que je ne comprends pas, comme le
> problème du <div class="change-cursor2crosshair">></div> qui encadre
> l'image, div lui même dans un <p></p>, ça dit :
> 8<-----------8<---------8<----------8<----------8<----------8<----------8<
> document type does not allow element "div" here; missing one of
> "object", "ins", "del", "map", "button" start-tag .
> 8<-----------8<---------8<----------8<----------8<----------8<----------8<

Ah, ça c'est parfaitement en charte ici !

Un paragraphe P ne peut contenir que des éléments de type « inline » :
http://www.la-grange.net/w3c/html4.01/struct/text.html#h-9.3.1

Or l'élément DIV est de type « block » :
http://www.la-grange.net/w3c/html4.01/sgml/dtd.html#block

Tu ne peux donc pas mettre un DIV dans un P.

Je vais tacher de m'en souvenir

Note que le message parlant des éléments « missing » est de nature à
induire en erreur. Il est vrai que tu peux mettre par exemple un INS
dans un P et un DIV dans un INS, mais en principe on ne devrait pas
avoir le droit de mettre un DIV dans un INS dans un P ! Seul le début
de la phrase est vraiment correct (tu n'as pas le droit de mettre un
DIV ici).

OK.
Mon problème est que j'ai beaucoup de mal à faire la distinction entre
bloc et inline. Il est difficile pour moi de retenir une définition
quand elle n'est pas claire, or on définit toujours block et inline en
opposition l'un par rapport à l'autre.
S'il y a un critère de la clarté d'une définition, c'est bien son
caractère standalone. Dès qu'on définit quelque chose en opposition à
une autre, je doute de la qualité du concept, (ou de la clarté de
celui-ci dans l'esprit de celui qui rédige la doc).
Bref, pas évident de retenir un truc quand il y a (dans mon esprit)
manque de cohérence.

Enfin, j'ai viré tous les <p></p> et il ne reste plus que l'erreur du
name dans le form. Ça fait quand même un peu illogique d'écrire sans
marque de paragraphe...

> Il y aussi <form name="Form1" action="#" onsubmit="return false;"> qui
> raconte :
> 8<-----------8<---------8<----------8<----------8<----------8<----------8<
> there is no attribute "name"
> [cut]
> 8<-----------8<---------8<----------8<----------8<----------8<----------8<
Là je ne comprends pas. L'attribut name dans un FORM ne devrait plus
être utilisé (et remplacé par id) mais normalement il est « conservé
pour la rétro-compatibilité » :
http://www.la-grange.net/w3c/html4.01/interact/forms.html#h-17.3

Si je supprime l'attribut name, le script javascript ne sait plus à quoi
je fais référence.
Je vais utiliser la ruse de SAM.

> Et deux autres erreurs du même tonneau que je ne comprends pas.
N'hésite pas à venir en parler ici.

OK, merci de ton aide.

--
Concours de bit entre linuxiens : hcgvzr
Hugo (né il y a 1 389 046 019 secondes)

Le Wed, 30 Apr 2008 03:14:49 +0200, Olivier Miakinen a écrit:

Le 30/04/2008 01:10, Hugolino a écrit :
>
> Le W3C Validator annonçait 117 erreurs, je suis tombé à 4 après un peu
> de nettoyage, mais il y a des trucs que je ne comprends pas, comme le
> problème du <div class="change-cursor2crosshair">></div> qui encadre
> l'image, div lui même dans un <p></p>, ça dit :
> 8<-----------8<---------8<----------8<----------8<----------8<----------8<
> document type does not allow element "div" here; missing one of
> "object", "ins", "del", "map", "button" start-tag .
> 8<-----------8<---------8<----------8<----------8<----------8<----------8<

Ah, ça c'est parfaitement en charte ici !

Un paragraphe P ne peut contenir que des éléments de type « inline » :
http://www.la-grange.net/w3c/html4.01/struct/text.html#h-9.3.1

Or l'élément DIV est de type « block » :
http://www.la-grange.net/w3c/html4.01/sgml/dtd.html#block

Tu ne peux donc pas mettre un DIV dans un P.

Je vais tacher de m'en souvenir

Note que le message parlant des éléments « missing » est de nature à
induire en erreur. Il est vrai que tu peux mettre par exemple un INS
dans un P et un DIV dans un INS, mais en principe on ne devrait pas
avoir le droit de mettre un DIV dans un INS dans un P ! Seul le début
de la phrase est vraiment correct (tu n'as pas le droit de mettre un
DIV ici).

OK.
Mon problème est que j'ai beaucoup de mal à faire la distinction entre
bloc et inline. Il est difficile pour moi de retenir une définition
quand elle n'est pas claire, or on définit toujours block et inline en
opposition l'un par rapport à l'autre.
S'il y a un critère de la clarté d'une définition, c'est bien son
caractère standalone. Dès qu'on définit quelque chose en opposition à
une autre, je doute de la qualité du concept, (ou de la clarté de
celui-ci dans l'esprit de celui qui rédige la doc).
Bref, pas évident de retenir un truc quand il y a (dans mon esprit)
manque de cohérence.

Enfin, j'ai viré tous les <p></p> et il ne reste plus que l'erreur du
name dans le form. Ça fait quand même un peu illogique d'écrire sans
marque de paragraphe...

> Il y aussi <form name="Form1" action="#" onsubmit="return false;"> qui
> raconte :
> 8<-----------8<---------8<----------8<----------8<----------8<----------8<
> there is no attribute "name"
> [cut]
> 8<-----------8<---------8<----------8<----------8<----------8<----------8<
Là je ne comprends pas. L'attribut name dans un FORM ne devrait plus
être utilisé (et remplacé par id) mais normalement il est « conservé
pour la rétro-compatibilité » :
http://www.la-grange.net/w3c/html4.01/interact/forms.html#h-17.3

Si je supprime l'attribut name, le script javascript ne sait plus à quoi
je fais référence.
Je vais utiliser la ruse de SAM.

> Et deux autres erreurs du même tonneau que je ne comprends pas.
N'hésite pas à venir en parler ici.

OK, merci de ton aide.

--
Concours de bit entre linuxiens : hcgvzr
Hugo (né il y a 1 389 046 019 secondes)

Vous avez filtré cet utilisateur ! Consultez son message

Le Wed, 30 Apr 2008 03:14:49 +0200, Olivier Miakinen a écrit:

Le 30/04/2008 01:10, Hugolino a écrit :
>
> Le W3C Validator annonçait 117 erreurs, je suis tombé à 4 après un peu
> de nettoyage, mais il y a des trucs que je ne comprends pas, comme le
> problème du <div class="change-cursor2crosshair">></div> qui encadre
> l'image, div lui même dans un <p></p>, ça dit :
> 8<-----------8<---------8<----------8<----------8<----------8<----------8<
> document type does not allow element "div" here; missing one of
> "object", "ins", "del", "map", "button" start-tag .
> 8<-----------8<---------8<----------8<----------8<----------8<----------8<

Ah, ça c'est parfaitement en charte ici !

Un paragraphe P ne peut contenir que des éléments de type « inline » :
http://www.la-grange.net/w3c/html4.01/struct/text.html#h-9.3.1

Or l'élément DIV est de type « block » :
http://www.la-grange.net/w3c/html4.01/sgml/dtd.html#block

Tu ne peux donc pas mettre un DIV dans un P.

Je vais tacher de m'en souvenir

Note que le message parlant des éléments « missing » est de nature à
induire en erreur. Il est vrai que tu peux mettre par exemple un INS
dans un P et un DIV dans un INS, mais en principe on ne devrait pas
avoir le droit de mettre un DIV dans un INS dans un P ! Seul le début
de la phrase est vraiment correct (tu n'as pas le droit de mettre un
DIV ici).

OK.
Mon problème est que j'ai beaucoup de mal à faire la distinction entre
bloc et inline. Il est difficile pour moi de retenir une définition
quand elle n'est pas claire, or on définit toujours block et inline en
opposition l'un par rapport à l'autre.
S'il y a un critère de la clarté d'une définition, c'est bien son
caractère standalone. Dès qu'on définit quelque chose en opposition à
une autre, je doute de la qualité du concept, (ou de la clarté de
celui-ci dans l'esprit de celui qui rédige la doc).
Bref, pas évident de retenir un truc quand il y a (dans mon esprit)
manque de cohérence.

Enfin, j'ai viré tous les <p></p> et il ne reste plus que l'erreur du
name dans le form. Ça fait quand même un peu illogique d'écrire sans
marque de paragraphe...

> Il y aussi <form name="Form1" action="#" onsubmit="return false;"> qui
> raconte :
> 8<-----------8<---------8<----------8<----------8<----------8<----------8<
> there is no attribute "name"
> [cut]
> 8<-----------8<---------8<----------8<----------8<----------8<----------8<
Là je ne comprends pas. L'attribut name dans un FORM ne devrait plus
être utilisé (et remplacé par id) mais normalement il est « conservé
pour la rétro-compatibilité » :
http://www.la-grange.net/w3c/html4.01/interact/forms.html#h-17.3

Si je supprime l'attribut name, le script javascript ne sait plus à quoi
je fais référence.
Je vais utiliser la ruse de SAM.

> Et deux autres erreurs du même tonneau que je ne comprends pas.
N'hésite pas à venir en parler ici.

OK, merci de ton aide.

--
Concours de bit entre linuxiens : hcgvzr
Hugo (né il y a 1 389 046 019 secondes)

Olivier Miakinen

01/05/2008 à 02:20

Le 01/05/2008 00:49, Hugolino a écrit :

Mon problème est que j'ai beaucoup de mal à faire la distinction entre
bloc et inline. Il est difficile pour moi de retenir une définition
quand elle n'est pas claire, or on définit toujours block et inline en
opposition l'un par rapport à l'autre.

Ça me semble plutôt assez simple. En gros, inline c'est du texte et bloc
ce sont des pavés de structuration. Et le paragraphe est justement *la*
notion la plus importante : dans un paragraphe tu n'as en principe que
du texte (éventuellement agrémenté de quelques images si elles sont bien
intégrées dans le texte lui-même), alors qu'un paragraphe est lui-même
un bloc (de texte) que l'on peut éventuellement intégrer dans d'autres
blocs.

S'il y a un critère de la clarté d'une définition, c'est bien son
caractère standalone. Dès qu'on définit quelque chose en opposition à
une autre, je doute de la qualité du concept, (ou de la clarté de
celui-ci dans l'esprit de celui qui rédige la doc).

Je suis d'accord. Du coup j'espère que mon explication t'aidera à y voir
plus clair.

Bref, pas évident de retenir un truc quand il y a (dans mon esprit)
manque de cohérence.

En fait, je t'encourage à lire le standard HTML 4.01, en anglais ou en
français selon ce qui t'est le plus facile.

Liens directs sur ce point particulier :
http://www.w3.org/TR/html4/struct/global.html#h-7.5.3
http://www.la-grange.net/w3c/html4.01/struct/global.html#h-7.5.3

Enfin, j'ai viré tous les <p></p> et il ne reste plus que l'erreur du
name dans le form. Ça fait quand même un peu illogique d'écrire sans
marque de paragraphe...

Je suis d'accord que c'est illogique. Quand tu auras lu et compris ce
qui précède, tu devrais savoir si tes <p></p> sont bien placés ou non
(c.-à-d. s'ils encadrent vraiment *un* paragraphe de texte). Si oui,
alors le DIV qui se trouve dedans devrait être un SPAN ; sinon, le DIV
est peut-être bon mais c'est le P qui doit se trouver à un niveau inférieur.

> Il y aussi <form name="Form1" action="#" onsubmit="return false;"> qui
> raconte :
> 8<-----------8<---------8<----------8<----------8<----------8<----------8<
> there is no attribute "name"
> [cut]
> 8<-----------8<---------8<----------8<----------8<----------8<----------8<

Si je supprime l'attribut name, le script javascript ne sait plus à quoi
je fais référence.

Mais si tu remplaces « name="Form1" » par « id="Form1" », tu gagnes sur
les trois tableaux : le script le trouvera, le validateur ne râlera pas,
et ton code sera plus propre.

Je vais utiliser la ruse de SAM.

Là encore c'est dommage, comme de supprimer toute marque de paragraphe.

Plus exactement : utiliser HTML 4.01 au lieu de XHTML est préférable à
plein d'égards, mais que ça ne t'empêche pas d'utiliser id au lieu de name.

Le 01/05/2008 00:49, Hugolino a écrit :

Mon problème est que j'ai beaucoup de mal à faire la distinction entre
bloc et inline. Il est difficile pour moi de retenir une définition
quand elle n'est pas claire, or on définit toujours block et inline en
opposition l'un par rapport à l'autre.

Ça me semble plutôt assez simple. En gros, inline c'est du texte et bloc
ce sont des pavés de structuration. Et le paragraphe est justement *la*
notion la plus importante : dans un paragraphe tu n'as en principe que
du texte (éventuellement agrémenté de quelques images si elles sont bien
intégrées dans le texte lui-même), alors qu'un paragraphe est lui-même
un bloc (de texte) que l'on peut éventuellement intégrer dans d'autres
blocs.

S'il y a un critère de la clarté d'une définition, c'est bien son
caractère standalone. Dès qu'on définit quelque chose en opposition à
une autre, je doute de la qualité du concept, (ou de la clarté de
celui-ci dans l'esprit de celui qui rédige la doc).

Je suis d'accord. Du coup j'espère que mon explication t'aidera à y voir
plus clair.

Bref, pas évident de retenir un truc quand il y a (dans mon esprit)
manque de cohérence.

En fait, je t'encourage à lire le standard HTML 4.01, en anglais ou en
français selon ce qui t'est le plus facile.

Liens directs sur ce point particulier :
http://www.w3.org/TR/html4/struct/global.html#h-7.5.3
http://www.la-grange.net/w3c/html4.01/struct/global.html#h-7.5.3

Enfin, j'ai viré tous les <p></p> et il ne reste plus que l'erreur du
name dans le form. Ça fait quand même un peu illogique d'écrire sans
marque de paragraphe...

Je suis d'accord que c'est illogique. Quand tu auras lu et compris ce
qui précède, tu devrais savoir si tes <p></p> sont bien placés ou non
(c.-à-d. s'ils encadrent vraiment *un* paragraphe de texte). Si oui,
alors le DIV qui se trouve dedans devrait être un SPAN ; sinon, le DIV
est peut-être bon mais c'est le P qui doit se trouver à un niveau inférieur.

> Il y aussi <form name="Form1" action="#" onsubmit="return false;"> qui
> raconte :
> 8<-----------8<---------8<----------8<----------8<----------8<----------8<
> there is no attribute "name"
> [cut]
> 8<-----------8<---------8<----------8<----------8<----------8<----------8<

Si je supprime l'attribut name, le script javascript ne sait plus à quoi
je fais référence.

Mais si tu remplaces « name="Form1" » par « id="Form1" », tu gagnes sur
les trois tableaux : le script le trouvera, le validateur ne râlera pas,
et ton code sera plus propre.

Je vais utiliser la ruse de SAM.

Là encore c'est dommage, comme de supprimer toute marque de paragraphe.

Plus exactement : utiliser HTML 4.01 au lieu de XHTML est préférable à
plein d'égards, mais que ça ne t'empêche pas d'utiliser id au lieu de name.

Vous avez filtré cet utilisateur ! Consultez son message

Le 01/05/2008 00:49, Hugolino a écrit :

Mon problème est que j'ai beaucoup de mal à faire la distinction entre
bloc et inline. Il est difficile pour moi de retenir une définition
quand elle n'est pas claire, or on définit toujours block et inline en
opposition l'un par rapport à l'autre.

Ça me semble plutôt assez simple. En gros, inline c'est du texte et bloc
ce sont des pavés de structuration. Et le paragraphe est justement *la*
notion la plus importante : dans un paragraphe tu n'as en principe que
du texte (éventuellement agrémenté de quelques images si elles sont bien
intégrées dans le texte lui-même), alors qu'un paragraphe est lui-même
un bloc (de texte) que l'on peut éventuellement intégrer dans d'autres
blocs.

S'il y a un critère de la clarté d'une définition, c'est bien son
caractère standalone. Dès qu'on définit quelque chose en opposition à
une autre, je doute de la qualité du concept, (ou de la clarté de
celui-ci dans l'esprit de celui qui rédige la doc).

Je suis d'accord. Du coup j'espère que mon explication t'aidera à y voir
plus clair.

Bref, pas évident de retenir un truc quand il y a (dans mon esprit)
manque de cohérence.

En fait, je t'encourage à lire le standard HTML 4.01, en anglais ou en
français selon ce qui t'est le plus facile.

Liens directs sur ce point particulier :
http://www.w3.org/TR/html4/struct/global.html#h-7.5.3
http://www.la-grange.net/w3c/html4.01/struct/global.html#h-7.5.3

Enfin, j'ai viré tous les <p></p> et il ne reste plus que l'erreur du
name dans le form. Ça fait quand même un peu illogique d'écrire sans
marque de paragraphe...

Je suis d'accord que c'est illogique. Quand tu auras lu et compris ce
qui précède, tu devrais savoir si tes <p></p> sont bien placés ou non
(c.-à-d. s'ils encadrent vraiment *un* paragraphe de texte). Si oui,
alors le DIV qui se trouve dedans devrait être un SPAN ; sinon, le DIV
est peut-être bon mais c'est le P qui doit se trouver à un niveau inférieur.

> Il y aussi <form name="Form1" action="#" onsubmit="return false;"> qui
> raconte :
> 8<-----------8<---------8<----------8<----------8<----------8<----------8<
> there is no attribute "name"
> [cut]
> 8<-----------8<---------8<----------8<----------8<----------8<----------8<

Si je supprime l'attribut name, le script javascript ne sait plus à quoi
je fais référence.

Mais si tu remplaces « name="Form1" » par « id="Form1" », tu gagnes sur
les trois tableaux : le script le trouvera, le validateur ne râlera pas,
et ton code sera plus propre.

Je vais utiliser la ruse de SAM.

Là encore c'est dommage, comme de supprimer toute marque de paragraphe.

Plus exactement : utiliser HTML 4.01 au lieu de XHTML est préférable à
plein d'égards, mais que ça ne t'empêche pas d'utiliser id au lieu de name.

SAM

01/05/2008 à 03:30

Hugolino a écrit :

Le Wed, 30 Apr 2008 10:18:56 +0200, SAM a écrit:

voir (application du DOM) :
<http://cjoint.com/?eEjHEGMLPw>

Que veux-tu dire par "application du DOM" ?

Comme tu l'as découvert :
voir le JS du code source du fichier en frame
pour un début de démo de JS s'adressant au DOM

Une variante :
<http://cjoint.com/data/fbdxrRLLGG.htm>

- et l'effet rotation de la Terre ?

Sur une seconde ? faudra que je vérifie.

Est-ce que seulement ça tournerait dans ce sens ?
De ttes façons je m'inquiète pas : j'ai dû en oublier :-)

La vitesse chute car la tension superficielle qui tracte la pièce fini
par baisser aussi devant la pièce à cause de la diffusion du liquide
vaisselle dans tout le cristallisoir.

J'avais bien dit que j'en oubliais.
(doit bien y avoir des histoires de frottements, d'inertie, de volume
d'eau déplacé, tant qu'on y est)

En fait, je pourrais mesurer l'influence de cette vitesse de diffusion
en mesurant l'influence du volume d'eau dans le cristallisoir sur la
trajectoire... On est pas couché :)

Rhalala !
Dès que le Ø du cristallisoir est connu, que l'eau et la goute ont été
pesées, les différentes constantes retrouvées, avec un poil de JS ça
devrait se faire presqu'automatiquement.
:-)

Le pesage de la goute de teepol qui doit passer entière sur la pièce, ça
doit pas être coton !

De toutes façons, il faut que je refasse la vidéo en mettant la pièce
loin du bord au moment du départ, en cadrant beaucoup plus serré et en
espérant que la pièce veuille bien se positionner dans le sens de la
largeur de l'image pour étaler le déplacement sur 640 px plutôt que 480.

et une baignoire, non ?

ou faire plusieurs vidéos (x expériences)

Oui, mais l'expérience ne marche qu'une fois. Après chaque essai, je
dois

oui, oui, bien sûr, et alors ?
yapas d'raison qu'il n'y ait que les élèves à marner, non mais !

mais faudrait alors que je demande qu'on m'installe un lit
de camp dans le labo :)

Pas d'bol, ce n'est pas possible : y a l'alarme la nuit.

Je voulais garder la possibilité de relever les coordonnées des deux
points plutôt que du centre, car ça permet de tenir compte de l'énergie
cinétique de rotation.

Là, j'ai rien compris.
(le centre reste pas au centre ?)

le TP a rapidement tourné à
l'apprentissage de l'analyse et du filtrage numérique des données pour
essayer de contrebalancer la pauvre qualité des mesures.

Pourtant ça doit être mieux qu'à la règle graduée, non?
Vous avez quand même pu arriver à qque chose ?
Bon, où sont les corrigés ?
Ou, au moins les fiches pédagogiques.

Passe en html au lieu de xhtml qui est très restrictif.

Oui, je me demande vraiment pourquoi j'ai choisi le xhtml... j'avais
encore du lire un article qui disait que ça apportait richesse, santé
et permettait le retour de l'être aimé :)

D'aucuns ne jurent que par lui.
C'est l'avenir, c'est l'assurance de faire propre, etc ...

var f = document.forms[0];

OK, je vais faire ça, car changer le doctype de toutes les pages, j'ai
pas le courage.

Je croyais tes pages d'exo générées par php ?

--
sm

Hugolino a écrit :

Le Wed, 30 Apr 2008 10:18:56 +0200, SAM a écrit:

voir (application du DOM) :
<http://cjoint.com/?eEjHEGMLPw>

Que veux-tu dire par "application du DOM" ?

Comme tu l'as découvert :
voir le JS du code source du fichier en frame
pour un début de démo de JS s'adressant au DOM

Une variante :
<http://cjoint.com/data/fbdxrRLLGG.htm>

- et l'effet rotation de la Terre ?

Sur une seconde ? faudra que je vérifie.

Est-ce que seulement ça tournerait dans ce sens ?
De ttes façons je m'inquiète pas : j'ai dû en oublier :-)

La vitesse chute car la tension superficielle qui tracte la pièce fini
par baisser aussi devant la pièce à cause de la diffusion du liquide
vaisselle dans tout le cristallisoir.

J'avais bien dit que j'en oubliais.
(doit bien y avoir des histoires de frottements, d'inertie, de volume
d'eau déplacé, tant qu'on y est)

En fait, je pourrais mesurer l'influence de cette vitesse de diffusion
en mesurant l'influence du volume d'eau dans le cristallisoir sur la
trajectoire... On est pas couché :)

Rhalala !
Dès que le Ø du cristallisoir est connu, que l'eau et la goute ont été
pesées, les différentes constantes retrouvées, avec un poil de JS ça
devrait se faire presqu'automatiquement.
:-)

Le pesage de la goute de teepol qui doit passer entière sur la pièce, ça
doit pas être coton !

De toutes façons, il faut que je refasse la vidéo en mettant la pièce
loin du bord au moment du départ, en cadrant beaucoup plus serré et en
espérant que la pièce veuille bien se positionner dans le sens de la
largeur de l'image pour étaler le déplacement sur 640 px plutôt que 480.

et une baignoire, non ?

ou faire plusieurs vidéos (x expériences)

Oui, mais l'expérience ne marche qu'une fois. Après chaque essai, je
dois

oui, oui, bien sûr, et alors ?
yapas d'raison qu'il n'y ait que les élèves à marner, non mais !

mais faudrait alors que je demande qu'on m'installe un lit
de camp dans le labo :)

Pas d'bol, ce n'est pas possible : y a l'alarme la nuit.

Je voulais garder la possibilité de relever les coordonnées des deux
points plutôt que du centre, car ça permet de tenir compte de l'énergie
cinétique de rotation.

Là, j'ai rien compris.
(le centre reste pas au centre ?)

le TP a rapidement tourné à
l'apprentissage de l'analyse et du filtrage numérique des données pour
essayer de contrebalancer la pauvre qualité des mesures.

Pourtant ça doit être mieux qu'à la règle graduée, non?
Vous avez quand même pu arriver à qque chose ?
Bon, où sont les corrigés ?
Ou, au moins les fiches pédagogiques.

Passe en html au lieu de xhtml qui est très restrictif.

Oui, je me demande vraiment pourquoi j'ai choisi le xhtml... j'avais
encore du lire un article qui disait que ça apportait richesse, santé
et permettait le retour de l'être aimé :)

D'aucuns ne jurent que par lui.
C'est l'avenir, c'est l'assurance de faire propre, etc ...

var f = document.forms[0];

OK, je vais faire ça, car changer le doctype de toutes les pages, j'ai
pas le courage.

Je croyais tes pages d'exo générées par php ?

--
sm

Vous avez filtré cet utilisateur ! Consultez son message

Hugolino a écrit :

Le Wed, 30 Apr 2008 10:18:56 +0200, SAM a écrit:

voir (application du DOM) :
<http://cjoint.com/?eEjHEGMLPw>

Que veux-tu dire par "application du DOM" ?

Comme tu l'as découvert :
voir le JS du code source du fichier en frame
pour un début de démo de JS s'adressant au DOM

Une variante :
<http://cjoint.com/data/fbdxrRLLGG.htm>

- et l'effet rotation de la Terre ?

Sur une seconde ? faudra que je vérifie.

Est-ce que seulement ça tournerait dans ce sens ?
De ttes façons je m'inquiète pas : j'ai dû en oublier :-)

La vitesse chute car la tension superficielle qui tracte la pièce fini
par baisser aussi devant la pièce à cause de la diffusion du liquide
vaisselle dans tout le cristallisoir.

J'avais bien dit que j'en oubliais.
(doit bien y avoir des histoires de frottements, d'inertie, de volume
d'eau déplacé, tant qu'on y est)

En fait, je pourrais mesurer l'influence de cette vitesse de diffusion
en mesurant l'influence du volume d'eau dans le cristallisoir sur la
trajectoire... On est pas couché :)

Rhalala !
Dès que le Ø du cristallisoir est connu, que l'eau et la goute ont été
pesées, les différentes constantes retrouvées, avec un poil de JS ça
devrait se faire presqu'automatiquement.
:-)

Le pesage de la goute de teepol qui doit passer entière sur la pièce, ça
doit pas être coton !

De toutes façons, il faut que je refasse la vidéo en mettant la pièce
loin du bord au moment du départ, en cadrant beaucoup plus serré et en
espérant que la pièce veuille bien se positionner dans le sens de la
largeur de l'image pour étaler le déplacement sur 640 px plutôt que 480.

et une baignoire, non ?

ou faire plusieurs vidéos (x expériences)

Oui, mais l'expérience ne marche qu'une fois. Après chaque essai, je
dois

oui, oui, bien sûr, et alors ?
yapas d'raison qu'il n'y ait que les élèves à marner, non mais !

mais faudrait alors que je demande qu'on m'installe un lit
de camp dans le labo :)

Pas d'bol, ce n'est pas possible : y a l'alarme la nuit.

Je voulais garder la possibilité de relever les coordonnées des deux
points plutôt que du centre, car ça permet de tenir compte de l'énergie
cinétique de rotation.

Là, j'ai rien compris.
(le centre reste pas au centre ?)

le TP a rapidement tourné à
l'apprentissage de l'analyse et du filtrage numérique des données pour
essayer de contrebalancer la pauvre qualité des mesures.

Pourtant ça doit être mieux qu'à la règle graduée, non?
Vous avez quand même pu arriver à qque chose ?
Bon, où sont les corrigés ?
Ou, au moins les fiches pédagogiques.

Passe en html au lieu de xhtml qui est très restrictif.

Oui, je me demande vraiment pourquoi j'ai choisi le xhtml... j'avais
encore du lire un article qui disait que ça apportait richesse, santé
et permettait le retour de l'être aimé :)

D'aucuns ne jurent que par lui.
C'est l'avenir, c'est l'assurance de faire propre, etc ...

var f = document.forms[0];

OK, je vais faire ça, car changer le doctype de toutes les pages, j'ai
pas le courage.

Je croyais tes pages d'exo générées par php ?

--
sm

SAM

01/05/2008 à 15:38

Olivier Miakinen a écrit :

Le 01/05/2008 00:49, Hugolino a écrit :
Bref, pas évident de retenir un truc quand il y a (dans mon esprit)
manque de cohérence.

Pour les principaux ;

inline : texte, image, span, em, tt, a, input, label, ...
block : P, div, h1, h2 ... hn, probablement object

table et form sont particuliers (ni inline ni block)
Par exemple, les éléments d'un form DOIVENT être dans un block (P de
préférence) ou plusieurs.

'input' et 'img' sont les seul inlines considérés comme blocks par les
css ... enfin ... je veux dire :
sont les seuls auxquels on peut appliquer des règles de dimensions

table et form peuvent bien entendu être dimensionnés pas CSS

Le JS appliqué aux tables est très différent entre celui IE et celui
"normal"

En fait, je t'encourage à lire le standard HTML 4.01, en anglais ou en
français selon ce qui t'est le plus facile.

Liens directs sur ce point particulier :
http://www.w3.org/TR/html4/struct/global.html#h-7.5.3
http://www.la-grange.net/w3c/html4.01/struct/global.html#h-7.5.3

Ha? ici je lis :
<P>aaaaaaaaa<DIV>bbbbbbbbb</DIV><DIV>ccccc<P>ccccc</DIV>

Donc le (Olivier)"en principe du inline dans les P"(/Olivier)
ne reste qu'une idée ? !

Mais si tu remplaces « name="Form1" » par « id="Form1" », tu gagnes sur
les trois tableaux : le script le trouvera, le validateur ne râlera pas,
et ton code sera plus propre.

mais ici :
<http://www.la-grange.net/w3c/html4.01/interact/forms.html#edef-FORM>
on nous dit que le 'name' est normal (implied)
il est seulement recommandé d'utiliser 'id'

Plus exactement : utiliser HTML 4.01 au lieu de XHTML est préférable à
plein d'égards, mais que ça ne t'empêche pas d'utiliser id au lieu de name.

Par contre je vois à l'url précédente que le 'name' est OBLIGATOIRE pour
chaque *élément* de 'form'.
(je pensais la chose facultative... que si nécessaire à l'appli ?)

Finalement, dans les exemples, hop! le 'name' est omis ... ! ?
(<http://www.la-grange.net/w3c/html4.01/interact/forms.html#edef-LABEL>)
Est-ce qu'un 'input' qui n'a qu'un id est envoyé avec le formulaire ?

Tout ça reste somme toute assez confus

--
sm

Olivier Miakinen a écrit :

Le 01/05/2008 00:49, Hugolino a écrit :

Bref, pas évident de retenir un truc quand il y a (dans mon esprit)
manque de cohérence.

Pour les principaux ;

inline : texte, image, span, em, tt, a, input, label, ...
block : P, div, h1, h2 ... hn, probablement object

table et form sont particuliers (ni inline ni block)
Par exemple, les éléments d'un form DOIVENT être dans un block (P de
préférence) ou plusieurs.

'input' et 'img' sont les seul inlines considérés comme blocks par les
css ... enfin ... je veux dire :
sont les seuls auxquels on peut appliquer des règles de dimensions

table et form peuvent bien entendu être dimensionnés pas CSS

Le JS appliqué aux tables est très différent entre celui IE et celui
"normal"

En fait, je t'encourage à lire le standard HTML 4.01, en anglais ou en
français selon ce qui t'est le plus facile.

Liens directs sur ce point particulier :
http://www.w3.org/TR/html4/struct/global.html#h-7.5.3
http://www.la-grange.net/w3c/html4.01/struct/global.html#h-7.5.3

Ha? ici je lis :
<P>aaaaaaaaa<DIV>bbbbbbbbb</DIV><DIV>ccccc<P>ccccc</DIV>

Donc le (Olivier)"en principe du inline dans les P"(/Olivier)
ne reste qu'une idée ? !

Mais si tu remplaces « name="Form1" » par « id="Form1" », tu gagnes sur
les trois tableaux : le script le trouvera, le validateur ne râlera pas,
et ton code sera plus propre.

mais ici :
<http://www.la-grange.net/w3c/html4.01/interact/forms.html#edef-FORM>
on nous dit que le 'name' est normal (implied)
il est seulement recommandé d'utiliser 'id'

Plus exactement : utiliser HTML 4.01 au lieu de XHTML est préférable à
plein d'égards, mais que ça ne t'empêche pas d'utiliser id au lieu de name.

Par contre je vois à l'url précédente que le 'name' est OBLIGATOIRE pour
chaque *élément* de 'form'.
(je pensais la chose facultative... que si nécessaire à l'appli ?)

Finalement, dans les exemples, hop! le 'name' est omis ... ! ?
(<http://www.la-grange.net/w3c/html4.01/interact/forms.html#edef-LABEL>)
Est-ce qu'un 'input' qui n'a qu'un id est envoyé avec le formulaire ?

Tout ça reste somme toute assez confus

--
sm

Vous avez filtré cet utilisateur ! Consultez son message

Olivier Miakinen a écrit :

Le 01/05/2008 00:49, Hugolino a écrit :
Bref, pas évident de retenir un truc quand il y a (dans mon esprit)
manque de cohérence.

Pour les principaux ;

inline : texte, image, span, em, tt, a, input, label, ...
block : P, div, h1, h2 ... hn, probablement object

table et form sont particuliers (ni inline ni block)
Par exemple, les éléments d'un form DOIVENT être dans un block (P de
préférence) ou plusieurs.

'input' et 'img' sont les seul inlines considérés comme blocks par les
css ... enfin ... je veux dire :
sont les seuls auxquels on peut appliquer des règles de dimensions

table et form peuvent bien entendu être dimensionnés pas CSS

Le JS appliqué aux tables est très différent entre celui IE et celui
"normal"

En fait, je t'encourage à lire le standard HTML 4.01, en anglais ou en
français selon ce qui t'est le plus facile.

Liens directs sur ce point particulier :
http://www.w3.org/TR/html4/struct/global.html#h-7.5.3
http://www.la-grange.net/w3c/html4.01/struct/global.html#h-7.5.3

Ha? ici je lis :
<P>aaaaaaaaa<DIV>bbbbbbbbb</DIV><DIV>ccccc<P>ccccc</DIV>

Donc le (Olivier)"en principe du inline dans les P"(/Olivier)
ne reste qu'une idée ? !

Mais si tu remplaces « name="Form1" » par « id="Form1" », tu gagnes sur
les trois tableaux : le script le trouvera, le validateur ne râlera pas,
et ton code sera plus propre.

mais ici :
<http://www.la-grange.net/w3c/html4.01/interact/forms.html#edef-FORM>
on nous dit que le 'name' est normal (implied)
il est seulement recommandé d'utiliser 'id'

Plus exactement : utiliser HTML 4.01 au lieu de XHTML est préférable à
plein d'égards, mais que ça ne t'empêche pas d'utiliser id au lieu de name.

Par contre je vois à l'url précédente que le 'name' est OBLIGATOIRE pour
chaque *élément* de 'form'.
(je pensais la chose facultative... que si nécessaire à l'appli ?)

Finalement, dans les exemples, hop! le 'name' est omis ... ! ?
(<http://www.la-grange.net/w3c/html4.01/interact/forms.html#edef-LABEL>)
Est-ce qu'un 'input' qui n'a qu'un id est envoyé avec le formulaire ?

Tout ça reste somme toute assez confus

--
sm

SAM

01/05/2008 à 15:55

Olivier Miakinen a écrit :

Le 01/05/2008 00:49, Hugolino a écrit :
Je vais utiliser la ruse de SAM.

Là encore c'est dommage,

Je ne vois pas pourquoi.
On n'a aucune obligation de personnaliser (id ou name) quoi que ce soit.
(sauf les éléments de formulaires, si j'ai bien compris)

Pour la question du JS, bien qu'aujourd'hui on ait le DOM à disposition,
l'arbre des forms existe toujours.
Dans le cas présent le JS ne s'occupe que d'éléments de formulaire,
autant se servir simplement du JS approprié.
La "ruse" pour repérer le formulaire et qui n'est pas de moi me semble
tout à fait conforme dans ce contexte.

comme de supprimer toute marque de paragraphe.

Oui da.

Plus exactement : utiliser HTML 4.01 au lieu de XHTML est préférable à
plein d'égards, mais que ça ne t'empêche pas d'utiliser id au lieu de name.

Normalement, et s'il y a nécessité de pouvoir repérer les éléments html
(CSS, scripts) if FAUT utiliser les IDs pour "nommer" ces éléments.

Seuls les éléments des formulaires pourront (ou devront si ces forms
sont susceptibles d'être envoyés au serveur) avoir des 'names'.
Habituellement ID et NAME sont identiques :
<input name="truc" id="truc" />

Exemples de codes :

xhtml :
(voir la question du fieldset : div conteneur ou pas ?)
(le validator dit que c'est OK)

<form action="#">
<p><label for="machin"> Remplissez le machin : </label>
<input name="machin" id="machin" type="text" />
</p>
<fieldset><legend>Choisir un machin</legend>
<label for="machin_1">le machin 1</label>
<input type=radio name="machin" id="machin_1" value="A" /><br />
<label for="machin_2">le machin 2</label>
<input type=radio name="machin" id="machin_2" value="B" /><br />
<label for="machin_3">le machin 3
<input type="radio" name="machins" id="machin_3" value="C" />
</label>
</fieldset>
</form>

html :

<form action="#">
<p><label for="machin"> Remplissez le machin : </label>
<input name="machin" id="machin" type="text">
</p>
<fieldset><legend>Choisir un machin</legend>
<label for="machin_1">le machin 1</label>
<input type=radio name="machins" id="machin_1" value="A"><br>
<label for="machin_2">le machin 2</label>
<input type=radio name="machins" id="machin_2" value="B"><br>
<label for="machin_3">le machin 3
<input type=radio name="machins" id="machin_3" value="C">
</label>
</fieldset>
</form>
<p><a href="#machin_1">aller au machin 1</a>
(NC 4 devrait y arriver bien que le DOM lui soit assez mystérieux)</p>
<p>
<a href="#machin_2" title="NC 4 devrait y arriver">
aller au machin 2
</a>
</p>
<p>
<a href="#machin">
aller au machin
<span>NC 4 devrait y arriver bien que faible en DOM</span>
</a>
</p>

css (dont ruse pour transformer du inline en block) :

a { background: none }
a:hover { position: relative; background: orange }
a span { position: absolute; border:1px solid; text-decoration: none;
background: #ffc; top: 0; left: 50px; width: 150px;
display: none; }
a:hover span { display: block; z-index: 90 }

/* facultatif */
label { background: skyblue }
p { margin-bottom: 400px; padding-bottom: 100px; }

Sans background pour le A, mon IE n'y arrive pô ?! :-(
C'est dingue !

--
sm

Olivier Miakinen a écrit :

Le 01/05/2008 00:49, Hugolino a écrit :

Je vais utiliser la ruse de SAM.

Là encore c'est dommage,

Je ne vois pas pourquoi.
On n'a aucune obligation de personnaliser (id ou name) quoi que ce soit.
(sauf les éléments de formulaires, si j'ai bien compris)

Pour la question du JS, bien qu'aujourd'hui on ait le DOM à disposition,
l'arbre des forms existe toujours.
Dans le cas présent le JS ne s'occupe que d'éléments de formulaire,
autant se servir simplement du JS approprié.
La "ruse" pour repérer le formulaire et qui n'est pas de moi me semble
tout à fait conforme dans ce contexte.

comme de supprimer toute marque de paragraphe.

Oui da.

Plus exactement : utiliser HTML 4.01 au lieu de XHTML est préférable à
plein d'égards, mais que ça ne t'empêche pas d'utiliser id au lieu de name.

Normalement, et s'il y a nécessité de pouvoir repérer les éléments html
(CSS, scripts) if FAUT utiliser les IDs pour "nommer" ces éléments.

Seuls les éléments des formulaires pourront (ou devront si ces forms
sont susceptibles d'être envoyés au serveur) avoir des 'names'.
Habituellement ID et NAME sont identiques :
<input name="truc" id="truc" />

Exemples de codes :

xhtml :
(voir la question du fieldset : div conteneur ou pas ?)
(le validator dit que c'est OK)

<form action="#">
<p><label for="machin"> Remplissez le machin : </label>
<input name="machin" id="machin" type="text" />
</p>
<fieldset><legend>Choisir un machin</legend>
<label for="machin_1">le machin 1</label>
<input type=radio name="machin" id="machin_1" value="A" /><br />
<label for="machin_2">le machin 2</label>
<input type=radio name="machin" id="machin_2" value="B" /><br />
<label for="machin_3">le machin 3
<input type="radio" name="machins" id="machin_3" value="C" />
</label>
</fieldset>
</form>

html :

<form action="#">
<p><label for="machin"> Remplissez le machin : </label>
<input name="machin" id="machin" type="text">
</p>
<fieldset><legend>Choisir un machin</legend>
<label for="machin_1">le machin 1</label>
<input type=radio name="machins" id="machin_1" value="A"><br>
<label for="machin_2">le machin 2</label>
<input type=radio name="machins" id="machin_2" value="B"><br>
<label for="machin_3">le machin 3
<input type=radio name="machins" id="machin_3" value="C">
</label>
</fieldset>
</form>
<p><a href="#machin_1">aller au machin 1</a>
(NC 4 devrait y arriver bien que le DOM lui soit assez mystérieux)</p>
<p>
<a href="#machin_2" title="NC 4 devrait y arriver">
aller au machin 2
</a>
</p>
<p>
<a href="#machin">
aller au machin
<span>NC 4 devrait y arriver bien que faible en DOM</span>
</a>
</p>

css (dont ruse pour transformer du inline en block) :

a { background: none }
a:hover { position: relative; background: orange }
a span { position: absolute; border:1px solid; text-decoration: none;
background: #ffc; top: 0; left: 50px; width: 150px;
display: none; }
a:hover span { display: block; z-index: 90 }

/* facultatif */
label { background: skyblue }
p { margin-bottom: 400px; padding-bottom: 100px; }

Sans background pour le A, mon IE n'y arrive pô ?! :-(
C'est dingue !

--
sm

Vous avez filtré cet utilisateur ! Consultez son message

Olivier Miakinen a écrit :

Le 01/05/2008 00:49, Hugolino a écrit :
Je vais utiliser la ruse de SAM.

Là encore c'est dommage,

Je ne vois pas pourquoi.
On n'a aucune obligation de personnaliser (id ou name) quoi que ce soit.
(sauf les éléments de formulaires, si j'ai bien compris)

Pour la question du JS, bien qu'aujourd'hui on ait le DOM à disposition,
l'arbre des forms existe toujours.
Dans le cas présent le JS ne s'occupe que d'éléments de formulaire,
autant se servir simplement du JS approprié.
La "ruse" pour repérer le formulaire et qui n'est pas de moi me semble
tout à fait conforme dans ce contexte.

comme de supprimer toute marque de paragraphe.

Oui da.

Plus exactement : utiliser HTML 4.01 au lieu de XHTML est préférable à
plein d'égards, mais que ça ne t'empêche pas d'utiliser id au lieu de name.

Normalement, et s'il y a nécessité de pouvoir repérer les éléments html
(CSS, scripts) if FAUT utiliser les IDs pour "nommer" ces éléments.

Seuls les éléments des formulaires pourront (ou devront si ces forms
sont susceptibles d'être envoyés au serveur) avoir des 'names'.
Habituellement ID et NAME sont identiques :
<input name="truc" id="truc" />

Exemples de codes :

xhtml :
(voir la question du fieldset : div conteneur ou pas ?)
(le validator dit que c'est OK)

<form action="#">
<p><label for="machin"> Remplissez le machin : </label>
<input name="machin" id="machin" type="text" />
</p>
<fieldset><legend>Choisir un machin</legend>
<label for="machin_1">le machin 1</label>
<input type=radio name="machin" id="machin_1" value="A" /><br />
<label for="machin_2">le machin 2</label>
<input type=radio name="machin" id="machin_2" value="B" /><br />
<label for="machin_3">le machin 3
<input type="radio" name="machins" id="machin_3" value="C" />
</label>
</fieldset>
</form>

html :

<form action="#">
<p><label for="machin"> Remplissez le machin : </label>
<input name="machin" id="machin" type="text">
</p>
<fieldset><legend>Choisir un machin</legend>
<label for="machin_1">le machin 1</label>
<input type=radio name="machins" id="machin_1" value="A"><br>
<label for="machin_2">le machin 2</label>
<input type=radio name="machins" id="machin_2" value="B"><br>
<label for="machin_3">le machin 3
<input type=radio name="machins" id="machin_3" value="C">
</label>
</fieldset>
</form>
<p><a href="#machin_1">aller au machin 1</a>
(NC 4 devrait y arriver bien que le DOM lui soit assez mystérieux)</p>
<p>
<a href="#machin_2" title="NC 4 devrait y arriver">
aller au machin 2
</a>
</p>
<p>
<a href="#machin">
aller au machin
<span>NC 4 devrait y arriver bien que faible en DOM</span>
</a>
</p>

css (dont ruse pour transformer du inline en block) :

a { background: none }
a:hover { position: relative; background: orange }
a span { position: absolute; border:1px solid; text-decoration: none;
background: #ffc; top: 0; left: 50px; width: 150px;
display: none; }
a:hover span { display: block; z-index: 90 }

/* facultatif */
label { background: skyblue }
p { margin-bottom: 400px; padding-bottom: 100px; }

Sans background pour le A, mon IE n'y arrive pô ?! :-(
C'est dingue !

--
sm

Olivier Miakinen

01/05/2008 à 18:51

Le 01/05/2008 15:38, SAM a écrit :

Liens directs sur ce point particulier :
http://www.w3.org/TR/html4/struct/global.html#h-7.5.3
http://www.la-grange.net/w3c/html4.01/struct/global.html#h-7.5.3

Ha? ici je lis :
<P>aaaaaaaaa<DIV>bbbbbbbbb</DIV><DIV>ccccc<P>ccccc</DIV>

Ce n'est pas le plus lisible, mais c'est correct en HTML 4.01 Strict.
Quand même, je trouverais plus lisible de fermer explicitement les
éléments P :
<P>aaaaaaaaa</P><DIV>bbbbbbbbb</DIV><DIV>ccccc<P>ccccc</P></DIV>

Donc le (Olivier)"en principe du inline dans les P"(/Olivier)
ne reste qu'une idée ? !

Ah, je n'ai pas dit que le inline n'était autorisé *que* dans des P, ou
en tout cas ce n'est pas ce que je voulais dire. On en a aussi dans des
H1 à H6 par exemple.

Cela dit, tu as raison sur le fond : caractériser block ou inline par
rapport au P n'est pas beaucoup plus pertinent que de les définir
l'un par rapport à l'autre. Mais la définition donnée dans les liens
ci-dessus me semble, elle, bien plus pertinente.

Plus exactement : utiliser HTML 4.01 au lieu de XHTML est préférable à
plein d'égards, mais que ça ne t'empêche pas d'utiliser id au lieu de name.

Par contre je vois à l'url précédente que le 'name' est OBLIGATOIRE pour
chaque *élément* de 'form'.
(je pensais la chose facultative... que si nécessaire à l'appli ?)

Les concepteurs ont dû supposer qu'un élément de formulaire n'avait de
sens que s'il pouvait effectivement renvoyer une valeur au serveur lors
de la soumission dudit formulaire.

Finalement, dans les exemples, hop! le 'name' est omis ... ! ?
(<http://www.la-grange.net/w3c/html4.01/interact/forms.html#edef-LABEL>)

Tu as raison. On trouve le même exemple dès le début :
<http://www.la-grange.net/w3c/html4.01/interact/forms.html#h-17.1>.

Il y a même un exemple sans name ni id, ce qui est surprenant même s'il
s'agit d'un « exemple déconseillé » :
<http://www.la-grange.net/w3c/html4.01/interact/forms.html#h-17.8>.

Se pourrait-il que ce soient de simples erreurs ?

Est-ce qu'un 'input' qui n'a qu'un id est envoyé avec le formulaire ?

Bonne question, je n'en sais rien. Et un INPUT qui n'a ni name ni id,
est-ce que sa valeur est envoyée telle quelle, sans « nom= » devant ?

Tout ça reste somme toute assez confus

Oui.

Le 01/05/2008 15:38, SAM a écrit :

Liens directs sur ce point particulier :
http://www.w3.org/TR/html4/struct/global.html#h-7.5.3
http://www.la-grange.net/w3c/html4.01/struct/global.html#h-7.5.3

Ha? ici je lis :
<P>aaaaaaaaa<DIV>bbbbbbbbb</DIV><DIV>ccccc<P>ccccc</DIV>

Ce n'est pas le plus lisible, mais c'est correct en HTML 4.01 Strict.
Quand même, je trouverais plus lisible de fermer explicitement les
éléments P :
<P>aaaaaaaaa</P><DIV>bbbbbbbbb</DIV><DIV>ccccc<P>ccccc</P></DIV>

Donc le (Olivier)"en principe du inline dans les P"(/Olivier)
ne reste qu'une idée ? !

Ah, je n'ai pas dit que le inline n'était autorisé *que* dans des P, ou
en tout cas ce n'est pas ce que je voulais dire. On en a aussi dans des
H1 à H6 par exemple.

Cela dit, tu as raison sur le fond : caractériser block ou inline par
rapport au P n'est pas beaucoup plus pertinent que de les définir
l'un par rapport à l'autre. Mais la définition donnée dans les liens
ci-dessus me semble, elle, bien plus pertinente.

Plus exactement : utiliser HTML 4.01 au lieu de XHTML est préférable à
plein d'égards, mais que ça ne t'empêche pas d'utiliser id au lieu de name.

Par contre je vois à l'url précédente que le 'name' est OBLIGATOIRE pour
chaque *élément* de 'form'.
(je pensais la chose facultative... que si nécessaire à l'appli ?)

Les concepteurs ont dû supposer qu'un élément de formulaire n'avait de
sens que s'il pouvait effectivement renvoyer une valeur au serveur lors
de la soumission dudit formulaire.

Finalement, dans les exemples, hop! le 'name' est omis ... ! ?
(<http://www.la-grange.net/w3c/html4.01/interact/forms.html#edef-LABEL>)

Tu as raison. On trouve le même exemple dès le début :
<http://www.la-grange.net/w3c/html4.01/interact/forms.html#h-17.1>.

Il y a même un exemple sans name ni id, ce qui est surprenant même s'il
s'agit d'un « exemple déconseillé » :
<http://www.la-grange.net/w3c/html4.01/interact/forms.html#h-17.8>.

Se pourrait-il que ce soient de simples erreurs ?

Est-ce qu'un 'input' qui n'a qu'un id est envoyé avec le formulaire ?

Bonne question, je n'en sais rien. Et un INPUT qui n'a ni name ni id,
est-ce que sa valeur est envoyée telle quelle, sans « nom= » devant ?

Tout ça reste somme toute assez confus

Oui.

Vous avez filtré cet utilisateur ! Consultez son message

Le 01/05/2008 15:38, SAM a écrit :

Liens directs sur ce point particulier :
http://www.w3.org/TR/html4/struct/global.html#h-7.5.3
http://www.la-grange.net/w3c/html4.01/struct/global.html#h-7.5.3

Ha? ici je lis :
<P>aaaaaaaaa<DIV>bbbbbbbbb</DIV><DIV>ccccc<P>ccccc</DIV>

Ce n'est pas le plus lisible, mais c'est correct en HTML 4.01 Strict.
Quand même, je trouverais plus lisible de fermer explicitement les
éléments P :
<P>aaaaaaaaa</P><DIV>bbbbbbbbb</DIV><DIV>ccccc<P>ccccc</P></DIV>

Donc le (Olivier)"en principe du inline dans les P"(/Olivier)
ne reste qu'une idée ? !

Ah, je n'ai pas dit que le inline n'était autorisé *que* dans des P, ou
en tout cas ce n'est pas ce que je voulais dire. On en a aussi dans des
H1 à H6 par exemple.

Cela dit, tu as raison sur le fond : caractériser block ou inline par
rapport au P n'est pas beaucoup plus pertinent que de les définir
l'un par rapport à l'autre. Mais la définition donnée dans les liens
ci-dessus me semble, elle, bien plus pertinente.

Plus exactement : utiliser HTML 4.01 au lieu de XHTML est préférable à
plein d'égards, mais que ça ne t'empêche pas d'utiliser id au lieu de name.

Par contre je vois à l'url précédente que le 'name' est OBLIGATOIRE pour
chaque *élément* de 'form'.
(je pensais la chose facultative... que si nécessaire à l'appli ?)

Les concepteurs ont dû supposer qu'un élément de formulaire n'avait de
sens que s'il pouvait effectivement renvoyer une valeur au serveur lors
de la soumission dudit formulaire.

Finalement, dans les exemples, hop! le 'name' est omis ... ! ?
(<http://www.la-grange.net/w3c/html4.01/interact/forms.html#edef-LABEL>)

Tu as raison. On trouve le même exemple dès le début :
<http://www.la-grange.net/w3c/html4.01/interact/forms.html#h-17.1>.

Il y a même un exemple sans name ni id, ce qui est surprenant même s'il
s'agit d'un « exemple déconseillé » :
<http://www.la-grange.net/w3c/html4.01/interact/forms.html#h-17.8>.

Se pourrait-il que ce soient de simples erreurs ?

Est-ce qu'un 'input' qui n'a qu'un id est envoyé avec le formulaire ?

Bonne question, je n'en sais rien. Et un INPUT qui n'a ni name ni id,
est-ce que sa valeur est envoyée telle quelle, sans « nom= » devant ?

Tout ça reste somme toute assez confus

Oui.

Indiquer la position de la souris : javascript ?

10 réponses

Veuillez sélectionner un problème