Un guetteur est enregistré sur l’objet document
pour l’évènement
load. Une fois la page chargée, vous devriez voir apparaître les
détails concernant cet évènement dans le tableau de droite.
Tests d’une série d’évènements de base.
Test des évènements mouseover, mouseout et mousemove.
DIV
sur lequel sont enregistrés deux guetteurs, l’un pour
l’évènement mouseover et l’autre pour l’évènement mouseout
DIV
DIV
contenant plusieurs balises SPAN
et sur lequel est enregistré un guetteur pour l’évènement mousemove.Choisissez "bloquant" pour un calque donné pour que l’évènement ne se propage pas au-delà de ce nœud.
Vous pouvez tester sur ce lien.
On teste ici notre méthode Document.createElement()
qui
appelle la vraie méthode Document.createElement()
déplacée
dans Document.DOM_createElement()
puis passe le nouveau
nœud dans la fonction DOM_addProperties()
.
Nous testons ici le mécanisme de déclenchement d’évènements.
Un guetteur est enregistré sur le DIV
#theDiv
pour l’évènement click. Nous enregistrons également un guetteur
pour notre évènement personnalisé (que nous avons nommé
MYCustomEvent).
La recommandation dit :
Si
un guetteur d’évènement est enregistré sur un nœud alors que l’évènement
est en train d’être traité sur ce nœud, ce guetteur ne sera pas
déclenché durant la phase en cours mais pourra l’être lors d’une phase
ultérieure du flux d’évènement.
Pour une situation identique, si l’on retire un guetteur au lieu d’en
ajouter un, la recommandation dit :
Si
un guetteur d’évènement est retiré d’un nœud alors que l’évènement
est en train d’être traité sur ce nœud, ce guetteur ne sera pas
déclenché par les actions en cours. Une fois retiré, le guetteur
d’évènement n’est jamais invoqué à nouveau (à moins d’être réenregistré
pour un traitement ultérieur).
J’ai donné là la traduction du passage en question dans les notes de travail
concernant le module Events
du
DOM
niveau 3. Le DOM niveau 2 dit la
même chose mais de façon un peu moins claire.
Ce test va nous permettre de vérifier les choses suivantes :
INPUT
, nous ajoutons un second guetteur sur cet élément.
Ce second guetteur ne doit pas être déclenchéINPUT
, nous ajoutons un guetteur sur l’élément
DIV
parent de cet élément INPUT
.
Ce guetteur devrait être déclenchéINPUT
. Durant le traitement de l’évènement click
sur cet élément, nous retirons le second guetteur. Ce second guetteur
ne doit pas être déclenché.Concernant le clonage d’un nœud et ce que l’on doit faire des guetteurs
d’évènements qui lui sont rattachés, la recommandation dit :
Quand
un objet
Node
est recopié en utilisant la méthode cloneNode
,
les objets EventListener
attachés au Node
source
ne sont pas rattachés au Node
copié. Si l'utilisateur souhaite
ajouter les mêmes objets EventListener
à la copie nouvellement
créée, il doit le faire manuellement.
La méthode Node.cloneNode()
native est déplacée vers
Node.DOM_cloneNode()
. Notre propre méthode Node.cloneNode()
appelle Node.DOM_cloneNode()
puis passe le nœud copié à la
fonction DOM_addProperties()
. On fait de même pour tous les enfants
de ce nœud si on a à faire à un clonage en profondeur.
On vérifie que les évènements ajoutés dans le modèle évènements du W3C (Évènements d’interface, de mutation…) fonctionnent toujours avec notre interface.
Bonne nouvelle : La gestion des évènements de mutation semble implémentée dans la récente version 8.0 (beta) d’Opera.
La recommandation indique que la chaîne des ancêtres de la cible de l’évènement jusqu’à la racine du document est déterminé avant le début du traitement de l’évènement ( Chapitre 1.2 sur la description du flux d’évènement).
Ce test va nous permettre de vérifier que les guetteurs enregistrés sur un nœud ancêtre de la cible retiré du document sont bien déclenchés.
eventPhase
property of event object was "2"(Target Phase) even though
Bubble Phase when object is the target object of eventdocument.addEventListener
fails on load and unloadEvent.timeStamp
is a number but should be a DateEventTarget
nodesEt sùrement d’autres…
Navigateur | Durée en millisecondes |
---|---|
Pour environ 400 éléments à traiter sur cette page | |
Firefox 1.0 | ±100 ms |
Mozilla 1.8a5 | ±100 ms |
Opera 7.54 | ±65 ms |
Opera 8.0b1 | ±25 ms (wow !) |
MSIE 6.0sp1 | ±155 ms au premier affichage, puis augmente par tranche de ±100 ms à chaque réactualisation ?! |
Ces résultats ont été obtenus sur un athlon XP 1800+ disposant de 768 Mo de RAM. Le problème concernant MSIE est plus ou moins résolu, cela est dù au fait que MSIE ne détruit pas les références aux nœuds manipulés dans un script, d’où une utilisation croissante de la mémoire utilisée par ce navigateur. Plus de détails sur cette page (Merci à Loufoque).
Propriété | Valeur |
---|---|
|
|
Propriétés génériques | |
type | |
eventPhase | |
bubbles | |
cancelable | |
timeStamp | |
view | |
Targets | |
currentTarget | |
target | |
relatedTarget | |
Propriétés relatives à la souris et au clavier | |
screen X,Y | |
client X,Y | |
page X,Y * | |
offset X,Y * | |
layer X,Y * | |
altKey | |
ctrlKey | |
metaKey | |
shiftKey | |
button | |
detail | |
keyCode * |
L’utilitaire Suivi des évènements
vous
permet de savoir quels sont les dix derniers types d’évènements gérés par
l’interface. Pratique dans le cas d’évènements se succédant rapidement (le
tableau des propriétés et l’utilitaire flux d’évènement
ne donnant d’information que sur le dernier évènement traité).
Cet utilitaire est désactivé par défaut mais peut être activé en cliquant sur l’icône d’activation.
L’utilitaire flux d’évènement
vous permet
de visualiser le cheminement effectué par l’évènement dans l’arbre du document
tout au long des différentes phases ainsi que les nœuds affectés par l’évènement.
L’utilitaire précise également pour chacun des nœuds si des guetteurs ont
été trouvés ou non et si les méthodes stopPropagation()
et
preventDefault()
ont été appellées.
Vous pouvez mettre en exergue dans le document les nœuds affectés en cliquant sur le nom du tag (actuellement, fonctionne mal sur Opera et pas du tout sur MSIE).
Enfin, l’utilitaire est désactivé par défaut, mais peut être activé en cliquant sur l’icône d’activation.