|
Publicité ' | |||||||||||||||||||||||
|
|
#1 |
|
Nouveau Membre du Club
![]() Inscription : mars 2010 Messages : 82 ![]() |
Bonjour,
J'ai une question sur les événements, j'ai compris qu'un événement pouvait se propager du haut vers le bas ou inverse dans l'arbre du DOM, et qu'on pouvait aussi stopper cette propagation. Mais en quoi c'est différent le sens dans lequel se propage l'événement ? ça change quoi dans une application ? Je ne vois pas de différence, par exemple, dans la méthode addEventListener* : je ne comprends pas l'utilité du 3ème argument booléen qui définie la manière dont l'événement va se propager. * rappel : http://www.quirksmode.org/js/events_advanced.html Merci de m'éclairer. |
|
|
00
|
|
|
#2 | ||
|
Expert Confirmé
![]() Inscription : octobre 2003 Messages : 2 886 ![]() |
Salut,
En fait, l'événement effectue un aller-retour. Il va de l'élément englobant vers la cible, puis fait le chemin inverse. Une illustration se trouve dans le brouillon de la spécification du DOM3. Le troisième paramètre de addEventListener() indique si l'élément courant accepte ou non la capture d'événement (phase descendante). Pour éviter le bouillonnement, il faut utiliser stopPropagation().Le bouillonnement cessera dès lors qu'il a rencontré stopPropagation() sur le chemin du retour. L'importance tient de l'interaction que peut avoir un événement sur les éléments environnants. Par exemple, si on imagine trois zones concentriques qui changent de couleur à la suite d'un clique. Si tu ne préviens pas le bouillonnement au niveau de la plus petite zone, toutes les zones changeront de couleur en cliquant dessus. En règle général, je pense qu'on laisse quasiment tous le paramètre useCapture d'addEventListener() à false et on ne s'occupe que du bouillonnement en utilisant stopPropagation(). C'est d'ailleurs la logique utilisée par jQuery. Illustration : Code :
|
||
|
|
10
|
|
|
#3 |
|
Nouveau Membre du Club
![]() Inscription : mars 2010 Messages : 82 ![]() |
D'accord, donc le problème vient uniquement du bouillonnement (ou du bubbling) ?
Le fait qu'un événement fasse juste l'aller (et non le retour) ne pose donc pas de problème ? Merci. |
|
|
00
|
|
|
#4 |
![]() ![]() ![]() Didier MouronvalDéveloppeur Web Inscription : juin 2008 Messages : 13 802 ![]() |
__________________
Pas de question technique par MP ! Tout le monde peut participer à developpez.com, vous avez une idée, contactez-moi ! Vous possédez un blog et aimeriez diffuser vos billets sur le forum, contactez-moi ! Mes formations video2brain : La formation complète sur JavaScript • JavaScript et le DOM par la pratique • PHP 5 et MySQL : les fondamentaux Mon livre sur jQuery
|
|
00
|
|
|
#5 |
|
Expert Confirmé
![]() Inscription : octobre 2003 Messages : 2 886 ![]() |
chok371, non, l'un comme l'autre peut causer des problèmes par méconnaissance ou oubli, mais peut aussi rendre service et être voulu.
Mes lectures sur le sujet commençaient à dater, je n'en ai donc pas parlé. IE gère ces événements d'une façon propre à lui. Le document proposé par Bovino l'explique. |
|
|
00
|
|
|
#6 | ||||
|
Membre chevronné
![]() Krusty Inscription : mai 2009 Messages : 472 ![]() |
j'ai pu aussi constater une difference entre le modele ie et celui de firefox chrome opera c'est la facon de recupere l'element d'ou provient l'evenement
var lui=e ? e.currentTarget : event.srcElement; exemple pour ie on notera qu'aucuns paramètres n'a été déclare Code :
<img src='blabla' id='monid' onclick='mafonction()'> Code :
Code :
<img src='blabla' id='monid' onclick='mafonction(event)'> Code :
ie accepte aussi cette syntaxe mais le probleme vient quand on fait un ajout dynamique d'evenement avec ie et attacheEvent on est obliger de passer par event.srcElement
__________________
programmer n'est pas connaitre tous les moindres détails d'un langage mais savoir exploiter sous toutes ses facettes ce que l'on connait. |
||||
|
|
00
|
|
|
#7 |
|
Nouveau Membre du Club
![]() Inscription : mars 2010 Messages : 82 ![]() |
Ok, merci je comprends mieux.
|
|
|
00
|
Copyright © 2000-2012 - www.developpez.com