implementation of event capture (incident Capture)
In the event model specification of the LEVEL2 DOM, events in the DOM tree propagate (from the root node to the target node) are divided into two phases: Capture (Capture) and bubbling (bubbling). The following diagram gives a general explanation of the whole process:
(from the Consortium)
If you want to create a capture event, it is good to set the third parameter of AddEventListener to true in browsers that support the event model for the consortium. For example:
Copy Code code as follows:
document.getElementById (' foo '). AddEventListener (' click ', function () {alert (' Hello, world! ');},true);
A little experiment was done in the last few years to try to understand the event capture, and in Firefox 2, Safari 3 on Windows and Opera 9, the event capture was practiced (of course, because IE does not support event capture, so ...). ), the principle of the experiment is shown in the following diagram:
The two elements with IDs Div1 and Div2 are bound to the capture-phase event-handler function, so that:
When you click #div1 (Blue area), you should alert out "Div1″
When clicked #div2 (yellow area), should alert out "Div1″, then alert out" Div2″, because in the event capture phase, the event is propagates down from the root element, #div1是 #div2 's parent element, the Click event that naturally binds on the #div1 will also precede the # The Click event on the DIV2 is executed.
However, the above scenario only applies to Firefox 2 and Safari 3 on Windows, and in Opera 9, things like this:
When you click on the #div1 (blue area), nothing happens.
When you click on the #div2 (yellow area), alert out "Div1″, then nothing happens again."
As you can see, in Opera 9, the Click event for the target element (targetelement) was not executed. Through the Realazy (Orz ...). The guidance, found this article: "Event capture Explained", found that the original opera in the realization is correct. There is a passage in this article that says:
The DOM spec states that capturing events should isn't fire on target and because the idea of a capturing event are to detect EV Ents before they reach their targets. Because of bugs in Gecko and Safari, Web content This is tested mostly with Firefox or other gecko-based browsers S expects capturing listeners to fire on target. Such content would fail in Opera 7, 8 and current releases of 9 because of its correct implementation of the standard.
The effect is that the event stated in the DOM specification should not be executed on the target element, because the purpose of the capture event is to monitor the event before the target element is reached. Firefox and Safari implementations are bug-prone.
Let's look at the words in the DOM events specification:
A capturing EventListener won't be triggered by events dispatched directly to the eventtarget upon which it is register Ed.
So, in the whole event propagation, the Order of execution is:
All capture events (if any) in the parent element are executed from top to bottom
Bubble event for Target element (if any)
All bubbling events (if any) in the parent element are executed from the bottom up
After understanding these, perhaps do not use event capture for the best, at least for the time being.
The problem of IE's Advanced event handling model
Duplicate binding
IE there is no addeventlistener, but also has its own attachevent, that is, the so-called Microsoft Model. The implementation of the two is basically the same as the first parameter (event type) of the attachevent needs to be added "on", while the AddEventListener does not, and the attachevent does not support event capture, so there is no third argument.
However, Attachevent also has a very fatal problem: duplicate binding events. (This is learned from PPK on JavaScript)
An example:
Copy Code code as follows:
function SayHello () {
Alert (' Hello, world! ');
}
The Model of the Consortium
$ (' Div1 '). AddEventListener (' Click ', SayHello, false);
$ (' Div1 '). AddEventListener (' Click ', SayHello, false);
Microsoft Model
$ (' Div1 '). attachevent (' onclick ', SayHello);
$ (' Div1 '). attachevent (' onclick ', SayHello);
In the model, the binding of the same event handler is ignored, that is, the second $ (' Div1 '). AddEventListener (' Click ', SayHello, false);
In the Microsoft model, the second $ (' Div1 '). attachevent (' onclick ', SayHello) is also executed, so when you click #div1, the alert box pops up two times. What's more, in detachevent time, also must detachevent two times to completely sayhello from #div1 's Click event to remove.
Why not continue using Alertid ()?
This is because of another flaw in IE's event model, which in Alertid uses the This keyword to refer to elements that are bound to the event handler, so that in the Alertid, this refers to #div1 or #div2.
However, in the Microsoft model, when support for this is missing, the this.id becomes undefined, because this is the time that this refers to the Window object.
