Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Scripting Microsoft Événement déclenché sur un objet erroné

Événement déclenché sur un objet erroné

22 réponses
Avatar
Claude Schneegans
Bonjour,

Regardez à l'adresse suivante:
http://www.contentbox.com/claude/test/testEvent.htm

Le script parcoure tous les éléments du document, et pour chaque élément
de liste LI,
il lui assigne un événement de type onmouseover

La fonction appelée par l'événement vérifie le nom de balise de l'objet,
ça devrait toujours être
un LI, mais ô surprise, des fois l'objet est le UL, et dans ce cas une
alarme est déclenchée.
Comment se peut-ce, puisqu'aucun UL n'a d'événement attaché ? Bizarre hein ?

Promenez la souris sur le menu, et tout d'un coup, pouf ! C'est un UL
qui déclenche.

Le plus curieux, c'est que Mords-y-la semble avoir le même problème.

Si c'est un comportement normal, j'aimerais bien en avoir une explication.

Merci.

Voilà le code :

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<html>
<head>
<title>Untitled</title>
<STYLE>
ul {
background-color: #B9D2FF;
margin:0px;
padding: 0;
position:absolute;
border: solid 1px #AAAAAA;
}
ul li {
width: 125px;
margin: 0;
padding: 0;
background-color: #628BFF;
color: #DFE6F5;
border: 1px outset;
list-style: none;
}
UL LI UL {
left:110px;
top:5px;
}
</STYLE>
</head>

<body>
<UL id="0">
<li id="1">item 1
<UL id="1.0">
<li id="1.1">item 1.1</li>
<li id="1.3">item 1.3</li>
<li id="1.4">item 1.4</li>
</ul></li>
<li id="2">item 2</li>
<li id="3">item 3</li>
<li id="4">item 4</li>
</ul>
<SCRIPT>
function init(m)
{
var el = m.childNodes;
for (var l = 0; l<el.length; l++)
{
if(el[l].tagName)
{
var tag = el[l].tagName.toLowerCase();
if (tag == "ul")
{
//do not attach event if UL container, but process its LIs
init (el[l]);
}
else if (tag == "li")
{
//attach event to list element ONLY
if(document.all)el[l].attachEvent('onmouseover', show);
else el[l].addEventListener("mouseover", show, false);
init (el[l]);
}
}
}
}
function show(e)
{
var li;
if (document.all)li=event.srcElement;
else li=e.target;
if (li.tagName != "LI")alert("over" + li.id + " : tag is " +
li.tagName);
}
init(document.body);
</SCRIPT>

</body>
</html>
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3
Avatar
Jean
ben non ... je rajoute les fermetures :

<UL>
<LI> ... Level one, number one...</LI>
<OL>
<LI> ... Level two, number one...</LI>
<LI> ... Level two, number two...</LI>
<OL start="10">
<LI> ... Level three, number one...</LI>
</OL>
<LI> ... Level two, number three...</LI>
</OL>
<LI> ... Level one, number two...</LI>
</UL>

Les LI "Level one" sont des éléments de la liste UL.
Les LI "Level two" sont des éléments de première la liste OL.
Les LI "Level three" sont des éléments de la seconde liste OL.

Les LI ne contiennent rien ... et les 2 OL sont contenues dans l'UL ...
Vous faites vos fermetures autrement ? ...

Bon, alors si je soumets votre code au valideur officiel du W3C :

http://validator.w3.org/check
Voici ce qu'il me sort :
« Line 11, column 7: document type does not allow element "OL" here; assuming
missing "LI" start-tag

<OL>

Line 14, column 21: document type does not allow element "OL" here; assuming
missing "LI" start-tag

<OL start="10"> »

Ce qui montre bien qu'une liste, OL ou UL, c'est pareil, ne peut contenir
directement d'autre éléments
UL ou OL : il faut un LI pour les contenir.

Par contre, si je remets les fermetures des LI au bon endroit, c-à-dire APRÈS
les fermetures des listes,
donc, le code a l'air de :

<UL>
<LI> ... Level one, number one...
<OL>
<LI> ... Level two, number one...</LI>
<LI> ... Level two, number two...
<OL start="10">
<LI> ... Level three, number one...</LI>
</OL></LI>
<LI> ... Level two, number three...</LI>
</OL></LI>
<LI> ... Level one, number two...</LI>
</UL>

la réponse est claire :
« The uploaded file was tentatively found to be Valid. »

C.Q.F.D



Effectivement ... je n'avais pas du tout compris celà comme ça.
Et le pire c'est que j'étais en train de valider des documents sur le
w3c ... :-)


Bon ... d'abord ce n'est pas parcequ'on le lit partout que c'est vrai
-) (c'est un lieu commun) et je préfère un lien issu d'un standard
pour confirmer.



Comme le validateur du W3C par exemple ;-)



Ou bon ça va hein ? :-) ... je mange mon chapeau :-)

Je dois dire que pour moi les LI ont tjrs été des éléments de liste et que
de plus ceux ci devaient être inclu dans un bloc de liste (ol, ul, dir,
menu ...) ... je n'aurais donc jamais eu l'idée de mettre une liste dans un
élément de liste (dans une LI racine) ...


La vraie façon dont il faut voir les choses, c'est que
1º une liste ne *PEUT PAS* contenir autre chose que des éléments de liste
<LI>, donc pas de texte ni d'autre liste;
2º un élément de liste LI *PEUT* contenir n'importe quoi, y compris d'autres
listes.

(là je me rapproche d'un méa culpa :-) )


Vous brûlez mon vieux ;-)



LOL ... oui bon ... ça va hein ? ... je ne vais pas le manger une
deuxième fois ... une fois ... :-)
"Deprecated", ça lui va bien je trouve :-)

Admettons que je raconte des âneries depuis le début.


Oui, mais là je sens que ça change ;-)



LOL ... l'honneur est sauf :O)

ou (pour conserver votre code tel quel, sans modifications dans la feuille
de style) en englobant les listes dans une SPAN par ex., le code donne le
résultat escompté et fonctionne correctement (cf code ci dessous).


En effet, et c'est bizarre, quel est le rapport ?
Avec une DIV, ça marche aussi, et avec une balise B également, mais avec un P
ça bug encore.
Et toujours de la même façon chez Mords-zy-la...


J'avais essayé div et span aussi (comme ce sont des éléments
génériques).
Après le premier café du matin, ce que je vois comme différence entre
div, span et b par rapport à une p c'est que les premières ont une
fermeture obligatoire et pas la P ...

--
Jean - JMST
Belgium



Avatar
Fred
Dans le message:,
ben non ... je rajoute les fermetures :

<UL>
<LI> ... Level one, number one...</LI>
<OL>
<LI> ... Level two, number one...</LI>
<LI> ... Level two, number two...</LI>
<OL start="10">
<LI> ... Level three, number one...</LI>
</OL>
<LI> ... Level two, number three...</LI>
</OL>
<LI> ... Level one, number two...</LI>
</UL>

Les LI "Level one" sont des éléments de la liste UL.
Les LI "Level two" sont des éléments de première la liste OL.
Les LI "Level three" sont des éléments de la seconde liste OL.

Les LI ne contiennent rien ... et les 2 OL sont contenues dans l'UL
... Vous faites vos fermetures autrement ? ...

Bon, alors si je soumets votre code au valideur officiel du W3C :

http://validator.w3.org/check
Voici ce qu'il me sort :
« Line 11, column 7: document type does not allow element "OL" here;
assuming missing "LI" start-tag

<OL>

Line 14, column 21: document type does not allow element "OL" here;
assuming missing "LI" start-tag

<OL start="10"> »

Ce qui montre bien qu'une liste, OL ou UL, c'est pareil, ne peut
contenir directement d'autre éléments
UL ou OL : il faut un LI pour les contenir.

Par contre, si je remets les fermetures des LI au bon endroit,
c-à-dire APRÈS les fermetures des listes,
donc, le code a l'air de :

<UL>
<LI> ... Level one, number one...
<OL>
<LI> ... Level two, number one...</LI>
<LI> ... Level two, number two...
<OL start="10">
<LI> ... Level three, number one...</LI>
</OL></LI>
<LI> ... Level two, number three...</LI>
</OL></LI>
<LI> ... Level one, number two...</LI>
</UL>

la réponse est claire :
« The uploaded file was tentatively found to be Valid. »

C.Q.F.D



Effectivement ... je n'avais pas du tout compris celà comme ça.
Et le pire c'est que j'étais en train de valider des documents sur le
w3c ... :-)


Bon ... d'abord ce n'est pas parcequ'on le lit partout que c'est
vrai
-) (c'est un lieu commun) et je préfère un lien issu d'un standard
pour confirmer.



Comme le validateur du W3C par exemple ;-)



Ou bon ça va hein ? :-) ... je mange mon chapeau :-)

Je dois dire que pour moi les LI ont tjrs été des éléments de liste
et que de plus ceux ci devaient être inclu dans un bloc de liste
(ol, ul, dir, menu ...) ... je n'aurais donc jamais eu l'idée de
mettre une liste dans un élément de liste (dans une LI racine) ...


La vraie façon dont il faut voir les choses, c'est que
1º une liste ne *PEUT PAS* contenir autre chose que des éléments de
liste <LI>, donc pas de texte ni d'autre liste;
2º un élément de liste LI *PEUT* contenir n'importe quoi, y compris
d'autres listes.

(là je me rapproche d'un méa culpa :-) )


Vous brûlez mon vieux ;-)



LOL ... oui bon ... ça va hein ? ... je ne vais pas le manger une
deuxième fois ... une fois ... :-)
"Deprecated", ça lui va bien je trouve :-)

Admettons que je raconte des âneries depuis le début.


Oui, mais là je sens que ça change ;-)



LOL ... l'honneur est sauf :O)

ou (pour conserver votre code tel quel, sans modifications dans la
feuille de style) en englobant les listes dans une SPAN par ex., le
code donne le résultat escompté et fonctionne correctement (cf code
ci dessous).


En effet, et c'est bizarre, quel est le rapport ?
Avec une DIV, ça marche aussi, et avec une balise B également, mais
avec un P ça bug encore.
Et toujours de la même façon chez Mords-zy-la...


J'avais essayé div et span aussi (comme ce sont des éléments
génériques).
Après le premier café du matin, ce que je vois comme différence entre
div, span et b par rapport à une p c'est que les premières ont une
fermeture obligatoire et pas la P ...


Bonjour,
C'est avec un grand intérêt que je suis votre petite conversation très
animée :-)
J'ai moi aussi fait quelques essais et il apparaît que c'est le LI contenant
le UL qui déclenche l'événement.
Mais comme le conteneur LI se confond avec le UL contenu, c'est le UL qui
est apparaît comme étant la source de l'événement.
(Il est à noter que si on supprime le positionnement absolu, le comportement
redevient normal)
Partant de là j'ai ajouté sur les UL un appel à une fonction "noshow" sur le
onmouseover.
Dans cette fonction je fais un cancelBubble pour éviter la transmission de
l'événement au parent (LI donc).
Bon je sais, cela ressemble à une rustine, mais cela fonctionne ;-)
Voila, je n'ai pas d'explication limpide mais seulement ce début. Je vous
laisse continuer :-)



--
Fred




Avatar
Jean
Dans le message:,
ben non ... je rajoute les fermetures :

<UL>
<LI> ... Level one, number one...</LI>
<OL>
<LI> ... Level two, number one...</LI>
<LI> ... Level two, number two...</LI>
<OL start="10">
<LI> ... Level three, number one...</LI>
</OL>
<LI> ... Level two, number three...</LI>
</OL>
<LI> ... Level one, number two...</LI>
</UL>

Les LI "Level one" sont des éléments de la liste UL.
Les LI "Level two" sont des éléments de première la liste OL.
Les LI "Level three" sont des éléments de la seconde liste OL.

Les LI ne contiennent rien ... et les 2 OL sont contenues dans l'UL
... Vous faites vos fermetures autrement ? ...

Bon, alors si je soumets votre code au valideur officiel du W3C :

http://validator.w3.org/check
Voici ce qu'il me sort :
« Line 11, column 7: document type does not allow element "OL" here;
assuming missing "LI" start-tag

<OL>

Line 14, column 21: document type does not allow element "OL" here;
assuming missing "LI" start-tag

<OL start="10"> »

Ce qui montre bien qu'une liste, OL ou UL, c'est pareil, ne peut
contenir directement d'autre éléments
UL ou OL : il faut un LI pour les contenir.

Par contre, si je remets les fermetures des LI au bon endroit,
c-à-dire APRÈS les fermetures des listes,
donc, le code a l'air de :

<UL>
<LI> ... Level one, number one...
<OL>
<LI> ... Level two, number one...</LI>
<LI> ... Level two, number two...
<OL start="10">
<LI> ... Level three, number one...</LI>
</OL></LI>
<LI> ... Level two, number three...</LI>
</OL></LI>
<LI> ... Level one, number two...</LI>
</UL>

la réponse est claire :
« The uploaded file was tentatively found to be Valid. »

C.Q.F.D



Effectivement ... je n'avais pas du tout compris celà comme ça.
Et le pire c'est que j'étais en train de valider des documents sur le
w3c ... :-)


Bon ... d'abord ce n'est pas parcequ'on le lit partout que c'est
vrai
-) (c'est un lieu commun) et je préfère un lien issu d'un standard
pour confirmer.



Comme le validateur du W3C par exemple ;-)



Ou bon ça va hein ? :-) ... je mange mon chapeau :-)

Je dois dire que pour moi les LI ont tjrs été des éléments de liste
et que de plus ceux ci devaient être inclu dans un bloc de liste
(ol, ul, dir, menu ...) ... je n'aurais donc jamais eu l'idée de
mettre une liste dans un élément de liste (dans une LI racine) ...


La vraie façon dont il faut voir les choses, c'est que
1º une liste ne *PEUT PAS* contenir autre chose que des éléments de
liste <LI>, donc pas de texte ni d'autre liste;
2º un élément de liste LI *PEUT* contenir n'importe quoi, y compris
d'autres listes.

(là je me rapproche d'un méa culpa :-) )


Vous brûlez mon vieux ;-)



LOL ... oui bon ... ça va hein ? ... je ne vais pas le manger une
deuxième fois ... une fois ... :-)
"Deprecated", ça lui va bien je trouve :-)

Admettons que je raconte des âneries depuis le début.


Oui, mais là je sens que ça change ;-)



LOL ... l'honneur est sauf :O)

ou (pour conserver votre code tel quel, sans modifications dans la
feuille de style) en englobant les listes dans une SPAN par ex., le
code donne le résultat escompté et fonctionne correctement (cf code
ci dessous).


En effet, et c'est bizarre, quel est le rapport ?
Avec une DIV, ça marche aussi, et avec une balise B également, mais
avec un P ça bug encore.
Et toujours de la même façon chez Mords-zy-la...


J'avais essayé div et span aussi (comme ce sont des éléments
génériques).
Après le premier café du matin, ce que je vois comme différence entre
div, span et b par rapport à une p c'est que les premières ont une
fermeture obligatoire et pas la P ...


Bonjour,
C'est avec un grand intérêt que je suis votre petite conversation très animée
:-)
J'ai moi aussi fait quelques essais et il apparaît que c'est le LI contenant
le UL qui déclenche l'événement.
Mais comme le conteneur LI se confond avec le UL contenu, c'est le UL qui est
apparaît comme étant la source de l'événement.
(Il est à noter que si on supprime le positionnement absolu, le comportement
redevient normal)
Partant de là j'ai ajouté sur les UL un appel à une fonction "noshow" sur le
onmouseover.
Dans cette fonction je fais un cancelBubble pour éviter la transmission de
l'événement au parent (LI donc).
Bon je sais, cela ressemble à une rustine, mais cela fonctionne ;-)
Voila, je n'ai pas d'explication limpide mais seulement ce début. Je vous
laisse continuer :-)


Ben j'en étais là aussi (après avoir compris le système de fermeture de
ces balises) et je crois que c'est la raison de son problème.
Comme l'événement onmouseover n'est pas défini sur l'UL id="1.0" c'est
l'event bubbling enclanche l'événement onmouseover de la LI id="1".
Et effectivement comme vous l'avez fait, en définissant un événement
onmouseover qui fait un cancelBubble=true pour l'UL id="1.0" le
problème devrait être résolu.

Sinon (sous IE) il peut aussi utiliser les événements onmouseenter et
onmouseleave qui consomment moins de ressource et ne font pas d'event
bubbling.

--
Jean - JMST
Belgium





Avatar
Claude Schneegans
ce que je vois comme différence entre div, span et b par rapport à une
p c'est que les premières ont une fermeture obligatoire et pas la P ...


En effet, mais encore là, en quoi ça peut influer sur le comportement
erratique des évènements ?

Un usager sur un groupe anglo m'a confirmé avoir remarqué le phénomène
également, sans pouvoir l'expliquer.

La morale de l'histoire, c'est que toute fonction de service d'un
événement devrait toujours vérifier
que ce dernier est vraiment légitime.

Puisque le problème est commun avec Mords-zy-la, je vais poser la
question dans un groupe pour Mords-zy-la.
L'ennui, c'est que les adeptes y sont tellement paranos que le simple
fait d'avoir l'air de soulever une critique,
si légère soit-elle, soulève un tollé général à chaque fois.
Par contre, si je leur annonce que IE commet la même bourde, ça fera
peut-être avaler la pilule ;-)

Avatar
Claude Schneegans
Mais comme le conteneur LI se confond avec le UL contenu, c'est le UL qui
est apparaît comme étant la source de l'événement.


Bon, d'accord, le UL est caché derrière le LI, raison de plus pour qu'il

se la ferme ;-)

(Il est à noter que si on supprime le positionnement absolu, le comportement
redevient normal)


Ok, mais le problème, c'est que j'en ai besoin moi de ce positionnement

absolu, sinon adieu le menu.

Partant de là j'ai ajouté sur les UL un appel à une fonction "noshow" sur le
onmouseover.


Oui, on peut faire comme ça, mais qui sait quel élément pourrait

éventuelement (sans jeu de mot) déclencher
l'Event ? Le BODY ? Quand on perd confiance dans le système, il faut se
munir de la ceinture et des bretelles.
Ce que je fais, c'est tester dans le onMouseOver si l'élément
déclencheur est bien un LI dûment mandaté.

Avatar
Claude Schneegans
Comme l'événement onmouseover n'est pas défini sur l'UL id="1.0" c'est
l'event bubbling enclanche l'événement onmouseover de la LI id="1".


Je croyais aussi, mais d'une part, si j'arrête la machine à bulle lors
de l'événement, ça ne change pas,
d'autre part, j'ai ajouté une façon de tracer le dernier événement
valide lors de l'alerte.
Si un événement sur un UL était déclenché par une remontée de bulle,
l'événement précédent proviendrait
d'un LI appartenant au UL en question, or ce n'est pratiquement jamais
le cas.
J'ai même vu un événement erroné se présenter en tout premier lieu.

C'est vraiment le déclencheur d'événements qui se trompe d'objet.

Avatar
Fred
Dans son message %
Claude Schneegans nous dit :

Bonjour,
Je réponds plutôt ici car une partie de ce message m'interpelle :-)

Comme l'événement onmouseover n'est pas défini sur l'UL id="1.0"
c'est
l'event bubbling enclanche l'événement onmouseover de la LI id="1".


Je croyais aussi, mais d'une part, si j'arrête la machine à bulle lors
de l'événement, ça ne change pas,
d'autre part, j'ai ajouté une façon de tracer le dernier événement
valide lors de l'alerte.
Si un événement sur un UL était déclenché par une remontée de bulle,
l'événement précédent proviendrait
d'un LI appartenant au UL en question, or ce n'est pratiquement jamais
le cas.


Dans mon essai, j'empêche la remontée de bulle de l'UL vers le LI contenant
(pas le contraire)
Soit l'UL 1.0 et le LI 1

Sinon, dans mon post j'ai fait une confusion quand j'écrivais :
[Mais comme le conteneur LI se confond avec le UL contenu, c'est le UL qui
est apparaît comme étant la source de l'événement.]
Plus précisément (et plus clairement ? pas sûr :-) :
Dans le modèle objet : LI 1 contient UL 1.0
Dans le rendu graphique : UL 1.0 n'est plus à l'intérieur de LI 1
L'événement se déclenche quand on passe sur la bordure du UL.
Le déclencheur se trompe effectivement d'objet. Il envoie l'événement du LI
car UL est supposé être dans le LI mais graphiquement parlant la souris est
sur l'UL.
Du moins c'est comme cela que je l'interprète. Je puis me tromper.

Cela me paraît lié davantage au CSS qu'au problème des balises fermées ou
pas.
D'ailleurs, à ce propos, j'ai oublié de signaler une autre manip qui évite
le déclenchement de l'événement sur un UL, c'est de mettre la bordure des UL
à 0.


J'ai même vu un événement erroné se présenter en tout premier lieu.

C'est vraiment le déclencheur d'événements qui se trompe d'objet.


Je le vois également comme cela. Mais j'aurais aimé trouvé une explication
rationnelle.


--
Fred


Avatar
Claude Schneegans


Du moins c'est comme cela que je l'interprète. Je puis me tromper.


Ça se tient en effet.


D'autre part, je trouve dans la doc de Microstuff à propos du « mouse
capture »
(
http://msdn.microsoft.com/workshop/author/dhtml/overview/mousecapture.asp )
« When a mouse event fires, the srcElement
</workshop/author/dhtml/reference/properties/srcelement.asp> property
exposed by the event
</workshop/author/dhtml/reference/objects/obj_event.asp> object returns
the object positioned under the mouse rather than the object with mouse
capture. »

... ce qui pourait expliquer, même si je n'utilise pas la fonction
*setCapture.*

Avatar
Jean
Comme l'événement onmouseover n'est pas défini sur l'UL id="1.0" c'est
l'event bubbling enclanche l'événement onmouseover de la LI id="1".


Je croyais aussi, mais d'une part, si j'arrête la machine à bulle lors de
l'événement, ça ne change pas,
d'autre part, j'ai ajouté une façon de tracer le dernier événement valide
lors de l'alerte.
Si un événement sur un UL était déclenché par une remontée de bulle,
l'événement précédent proviendrait
d'un LI appartenant au UL en question, or ce n'est pratiquement jamais le
cas.
J'ai même vu un événement erroné se présenter en tout premier lieu.

C'est vraiment le déclencheur d'événements qui se trompe d'objet.


Je suppose que c'est ce qui vous fait dire ailleurs :

"There is absolutely no valid reason why an UL element with NO event
handler should fire an event attached to
another element, even if this element is a child."

Or justement, ça fait partie du fonctionnement de l'event bubbling ...
sinon un simple :

function document.onclick(){
alert(event.srcElement)
}

... retournerait toujours la même chose :-)


Voir ici :

Understanding the Event Model :
http://msdn.microsoft.com/library/default.asp?url=/workshop/author/om/event_model.asp

<extrait>
"For events that bubble, if there is no event handler bound to the
source element, the event handler for the next element up the hierarchy
is called."
</extrait>

Avec votre code , dans l'état actuel, vous aurez de toute façon du mal
a vous passer du cancelBubble parceque bubbling aidant la fonction
show() s'executera 2 fois pour les éléments LI d'id=1.1,1.2 et 1.4 : la
leur (il ne manquerait plus que ça :-) + celle de l'élément LI d'id=1
(à cause du bubbling, cf plus haut).

Reste à voir l'objectif de votre code.
Dans la mesure ou le handler (show) est toujours le même pourquoi ne
pas profiter par exemple (hum ... le mot est peut être exagéré) du
bubbling autrement en mettant le handler uniquement sur le plus haut
parent (l'élément UL d'id 0 dans votre code) ? ... comme dans le code
ci dessous :

<!---8<--->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>Untitled</title>
<style>
ul {
background-color: #B9D2FF;
margin:0px;
padding: 0;
position:absolute;
border: solid 1px #AAAAAA;
left:200px;
}
ul li {
width: 125px;
margin: 0;
padding: 0;
background-color: #628BFF;
color: #DFE6F5;
border: 1px outset;
list-style: none;
}
ul li ul {
left:110px;
top:5px;
}
</style>
</head>

<body>

<ul id="U0">
<li id="L1">item 1
<ul id="U10">
<li id="L11">item 1.1</li>
<li id="L12">item 1.2</li>
<li id="L13">item 1.3</li>
</ul>
</li>
<li id="L2">item 2
</li>
<li id="L3">item 3</li>
<li id="L4">item 4</li>
</ul>

<div idÑ style='background-color:lemonchiffon'></div>

<script>
document.getElementsByTagName('ul')[0]
.attachEvent('onmouseover', show)
// U0.onmouseover=show

function show(){
with(event.srcElement){
if(tagName.toLowerCase()=='ul'){return false}
D1.innerText='id : '+id+' tagName : '+tagName
}
}
</script>

</body>
</html>
<!---8<--->

Amicalement,

--
Jean - JMST
Belgium


Avatar
Claude Schneegans
Or justement, ça fait partie du fonctionnement de l'event bubbling ...


Ouais, je crois que la clé du problème est là.
À mon tour d'avouer avoir mal compris le fonctionnement de srcElement.
Je pensais que "Object that receives the event that fired" ça désignait
l'élément auquel est attaché l'événement.
Or il appert que ça désigne plutôt celui qui a déclenché le processus au
départ.
Mon sens cartésien m'aura mal guidé, car en effet, qu'est que ça peut
bien me ?%$&?* de savoir quel est l'élément
déclencheur, ce qui m'intéresse, c'est de connaître l'élément que MOI
j'avais choisi pour être mis au courant
de l'événement.

Décidément, ce standard W3C a été établi par des sombres crétins qui
n'ont jamais aligné deux lignes de code dans leur vie. ;-)

1 2 3