http://www.quirksmode.org/js/events_advanced.html

에서 참조

Advanced event registration models

See section 7C of the book.

The W3C model is supported by Mozilla, Safari, Konqueror, and iCab.

The Microsoft model is supported by Explorer 5+ on Windows.

Opera supports both models.

On this page I explain the two advanced event registration models: W3C’s and Microsoft’s. Since neither is cross–browser supported, their use is, for the moment, deprecated.

W3C and Microsoft have both developed their own event registration model to replace Netscape’s traditional model. Though I’m not impressed by the Microsoft model, W3C’s is very good, except for one crucial vagueness. Unfortunately few browsers support it at the moment.

W3C

W3C’s DOM Level 2 Event specification pays careful attention to the problems of the traditional model. It offers a simple way to register as many event handlers as you like for the same event on one element.

The key to the W3C event registration model is the method addEventListener(). You give it three arguments: the event type, the function to be executed and a boolean (true or false) that I’ll explain later on. To register our well known doSomething() function to the onclick of an element you do:

element.addEventListener('click',doSomething,false)

The beauty of this model is that we can add as many event listeners as we want to the element. If we take our example modules from the traditional model page, we’d register them both as follows:

element.addEventListener('click',startDragDrop,false)

element.addEventListener('click',spyOnUser,false)

and both event handlers fire when the user clicks on the element. Please note that the W3C model does not state which event handler is fired first, so you cannot assume startDragDrop() is executed before spyOnUser().

To remove an event handler, use the removeEventListener() method. You can choose which handler to remove, so

element.removeEventListener('click',spyOnUser,false)

removes the second event handler but leaves the first one untouched. Beautiful functionality, and it exactly solves the problem with the traditional model we noted before.

Anonymous functions

You can also use anonymous functions in the W3C model:

element.addEventListener('click',function () {

	this.style.backgroundColor = '#cc0000'

},false)

true or false

As to the true or false that is the last argument of addEventListener, it is meant to state whether the event handler should be executed in the capturing or in the bubbling phase. If you’re not certain whether you want capturing or bubbling, use false (bubbling).

this

In JavaScript the this keyword always refers to the “owner” of a function. In the case of event handlers it is very useful if this refers to the HTML element the event is handled by, so that you have easy access to it.

Unfortunately the this keyword, though very powerful, is hard to use if you don’t know exactly how it works. I discuss its use on another page.

In the W3C model it works the same as in the traditional model: it refers to the HTML element currently handling the event.

element.addEventListener('click',doSomething,false);

another_element.addEventListener('click',doSomething,false);



function doSomething() {

	this.style.backgroundColor = '#cc0000';

}

If you register doSomething() as the click event handler of any HTML element, that element gets a red background whenever the user clicks on it.

Which event handlers are registered?

One problem of the current implementation of W3C’s event registration model is that you can’t find out if any event handlers are already registered to an element. In the traditional model you could do:

alert(element.onclick)

and you see the function that’s registered to it, or undefined if nothing is registered. Only in its very recent DOM Level 3 Events W3C adds an eventListenerList to store a list of event handlers that are currently registered on an element. This functionality is not yet supported by any browser, it’s too new. However, the problem has been addressed.

Fortunately removeEventListener() doesn’t give any errors if the event listener you want to remove has not been added to the element, so when in doubt you can always use removeEventListener().

Microsoft

Microsoft, too, has developed an event registration model. It looks similar to W3C’s, but has some important drawbacks.

To register an event handler, attach it to the element:

element.attachEvent('onclick',doSomething)

or, if you need two event handlers:

element.attachEvent('onclick',startDragDrop)

element.attachEvent('onclick',spyOnUser)

Removing one is simple, too:

element.detachEvent('onclick',spyOnUser)

Drawbacks

When compared to the W3C model, the Microsoft model has two important drawbacks:

  1. Events always bubble, no capturing possibility.
  2. The event handling function is referenced, not copied, so the this keyword always refers to the window and is completely useless.

The result of these two weaknesses is that when an event bubbles up it is impossible to know which HTML element currently handles the event. I explain this problem more fully on the Event order page.

Since the Microsoft event adding model is only supported by Explorer 5 and higher on Windows, it cannot be used for cross–browser scripts. But even for Explorer–on–Windows only applications it’s best not to use it, since the bubbling problem can be quite nasty in complex applications.

Continue

If you wish to go through all event pages in order, you should now continue with the Event accessing page

http://www.quirksmode.org/js/events_advanced.html

에서 참조

Advanced event registration models

See section 7C of the book.

The W3C model is supported by Mozilla, Safari, Konqueror, and iCab.

The Microsoft model is supported by Explorer 5+ on Windows.

Opera supports both models.

On this page I explain the two advanced event registration models: W3C’s and Microsoft’s. Since neither is cross–browser supported, their use is, for the moment, deprecated.

W3C and Microsoft have both developed their own event registration model to replace Netscape’s traditional model. Though I’m not impressed by the Microsoft model, W3C’s is very good, except for one crucial vagueness. Unfortunately few browsers support it at the moment.

W3C

W3C’s DOM Level 2 Event specification pays careful attention to the problems of the traditional model. It offers a simple way to register as many event handlers as you like for the same event on one element.

The key to the W3C event registration model is the method addEventListener(). You give it three arguments: the event type, the function to be executed and a boolean (true or false) that I’ll explain later on. To register our well known doSomething() function to the onclick of an element you do:

element.addEventListener('click',doSomething,false)

The beauty of this model is that we can add as many event listeners as we want to the element. If we take our example modules from the traditional model page, we’d register them both as follows:

element.addEventListener('click',startDragDrop,false)

element.addEventListener('click',spyOnUser,false)

and both event handlers fire when the user clicks on the element. Please note that the W3C model does not state which event handler is fired first, so you cannot assume startDragDrop() is executed before spyOnUser().

To remove an event handler, use the removeEventListener() method. You can choose which handler to remove, so

element.removeEventListener('click',spyOnUser,false)

removes the second event handler but leaves the first one untouched. Beautiful functionality, and it exactly solves the problem with the traditional model we noted before.

Anonymous functions

You can also use anonymous functions in the W3C model:

element.addEventListener('click',function () {

	this.style.backgroundColor = '#cc0000'

},false)

true or false

As to the true or false that is the last argument of addEventListener, it is meant to state whether the event handler should be executed in the capturing or in the bubbling phase. If you’re not certain whether you want capturing or bubbling, use false (bubbling).

this

In JavaScript the this keyword always refers to the “owner” of a function. In the case of event handlers it is very useful if this refers to the HTML element the event is handled by, so that you have easy access to it.

Unfortunately the this keyword, though very powerful, is hard to use if you don’t know exactly how it works. I discuss its use on another page.

In the W3C model it works the same as in the traditional model: it refers to the HTML element currently handling the event.

element.addEventListener('click',doSomething,false);

another_element.addEventListener('click',doSomething,false);



function doSomething() {

	this.style.backgroundColor = '#cc0000';

}

If you register doSomething() as the click event handler of any HTML element, that element gets a red background whenever the user clicks on it.

Which event handlers are registered?

One problem of the current implementation of W3C’s event registration model is that you can’t find out if any event handlers are already registered to an element. In the traditional model you could do:

alert(element.onclick)

and you see the function that’s registered to it, or undefined if nothing is registered. Only in its very recent DOM Level 3 Events W3C adds an eventListenerList to store a list of event handlers that are currently registered on an element. This functionality is not yet supported by any browser, it’s too new. However, the problem has been addressed.

Fortunately removeEventListener() doesn’t give any errors if the event listener you want to remove has not been added to the element, so when in doubt you can always use removeEventListener().

Microsoft

Microsoft, too, has developed an event registration model. It looks similar to W3C’s, but has some important drawbacks.

To register an event handler, attach it to the element:

element.attachEvent('onclick',doSomething)

or, if you need two event handlers:

element.attachEvent('onclick',startDragDrop)

element.attachEvent('onclick',spyOnUser)

Removing one is simple, too:

element.detachEvent('onclick',spyOnUser)

Drawbacks

When compared to the W3C model, the Microsoft model has two important drawbacks:

  1. Events always bubble, no capturing possibility.
  2. The event handling function is referenced, not copied, so the this keyword always refers to the window and is completely useless.

The result of these two weaknesses is that when an event bubbles up it is impossible to know which HTML element currently handles the event. I explain this problem more fully on the Event order page.

Since the Microsoft event adding model is only supported by Explorer 5 and higher on Windows, it cannot be used for cross–browser scripts. But even for Explorer–on–Windows only applications it’s best not to use it, since the bubbling problem can be quite nasty in complex applications.

Continue

If you wish to go through all event pages in order, you should now continue with the Event accessing page

http://www.quirksmode.org/js/events_order.html

에서 참조

 

Event order

See section 7D of the book.

Netscape 4 only supports event capturing, Explorer only supports event bubbling. Netscape 6 and Konqueror support both, while Opera and iCab support neither.

On the Introduction to events page I asked a question that at first sight seems incomprehensible: “If an element and one of its ancestors have an event handler for the same event, which one should fire first?” Not surprisingly, this depends on the browser.

The basic problem is very simple. Suppose you have a element inside an element

-----------------------------------

| element1                        |

|   -------------------------     |

|   |element2               |     |

|   -------------------------     |

|                                 |

-----------------------------------

and both have an onClick event handler. If the user clicks on element2 he causes a click event in both element1 and element2. But which event fires first? Which event handler should be executed first? What, in other words, is the event order?

Two models

Not surprisingly, back in the bad old days Netscape and Microsoft came to different conclusions.

  • Netscape said that the event on element1 takes place first. This is called event capturing.
  • Microsoft maintained that the event on element2 takes precedence. This is called event bubbling.

The two event orders are radically opposed. Explorer only supports event bubbling. Mozilla, Opera 7 and Konqueror support both. Older Opera’s and iCab support neither.

Event capturing

When you use event capturing

               | |

---------------| |-----------------

| element1     | |                |

|   -----------| |-----------     |

|   |element2   /          |     |

|   -------------------------     |

|        Event CAPTURING          |

-----------------------------------

the event handler of element1 fires first, the event handler of element2 fires last.

Event bubbling

When you use event bubbling

               / 

---------------| |-----------------

| element1     | |                |

|   -----------| |-----------     |

|   |element2  | |          |     |

|   -------------------------     |

|        Event BUBBLING           |

-----------------------------------

the event handler of element2 fires first, the event handler of element1 fires last.

W3C model

W3C has very sensibly decided to take a middle position in this struggle. Any event taking place in the W3C event model is first captured until it reaches the target element and then bubbles up again.

                 | |  / 

-----------------| |--| |-----------------

| element1       | |  | |                |

|   -------------| |--| |-----------     |

|   |element2     /  | |          |     |

|   --------------------------------     |

|        W3C event model                 |

------------------------------------------

You, the web developer, can choose whether to register an event handler in the capturing or in the bubbling phase. This is done through the addEventListener() method explained on the Advanced models page. If its last argument is true the event handler is set for the capturing phase, if it is false the event handler is set for the bubbling phase.

Suppose you do

element1.addEventListener('click',doSomething2,true)

element2.addEventListener('click',doSomething,false)

If the user clicks on element2 the following happens:

  1. The click event starts in the capturing phase. The event looks if any ancestor element of element2 has a onclick event handler for the capturing phase.
  2. The event finds one on element1. doSomething2() is executed.
  3. The event travels down to the target itself, no more event handlers for the capturing phase are found. The event moves to its bubbling phase and executes doSomething(), which is registered to element2 for the bubbling phase.
  4. The event travels upwards again and checks if any ancestor element of the target has an event handler for the bubbling phase. This is not the case, so nothing happens.

The reverse would be

element1.addEventListener('click',doSomething2,false)

element2.addEventListener('click',doSomething,false)

Now if the user clicks on element2 the following happens:

  1. The click event starts in the capturing phase. The event looks if any ancestor element of element2 has a onclick event handler for the capturing phase and doesn’t find any.
  2. The event travels down to the target itself. The event moves to its bubbling phase and executes doSomething(), which is registered to element2 for the bubbling phase.
  3. The event travels upwards again and checks if any ancestor element of the target has an event handler for the bubbling phase.
  4. The event finds one on element1. Now doSomething2() is executed.

Compatibility with traditional model

In the browsers that support the W3C DOM, a traditional event registration

element1.onclick = doSomething2;

is seen as a registration in the bubbling phase.

Use of event bubbling

Few web developers consciously use event capturing or bubbling. In Web pages as they are made today, it is simply not necessary to let a bubbling event be handled by several different event handlers. Users might get confused by several things happening after one mouse click, and usually you want to keep your event handling scripts separated. When the user clicks on an element, something happens, when he clicks on another element, something else happens.

Of course this might change in the future, and it’s good to have models available that are forward compatible. But the main practical use of event capturing and bubbling today is the registration of default functions.

It always happens

What you first need to understand is that event capturing or bubbling always happens. If you define a general onclick event handler for your entire document

document.onclick = doSomething;

if (document.captureEvents) document.captureEvents(Event.CLICK);

any click event on any element in the document will eventually bubble up to the document and thus fire this general event handler. Only when a previous event handling script explicitly orders the event to stop bubbling, it will not propagate to the document.

Uses

Because any event ends up on the document, default event handlers become possible. Suppose you have this page:

------------------------------------

| document                         |

|   ---------------  ------------  |

|   | element1    |  | element2 |  |

|   ---------------  ------------  |

|                                  |

------------------------------------



element1.onclick = doSomething;

element2.onclick = doSomething;

document.onclick = defaultFunction;

Now if the user clicks on element1 or 2, doSomething() is executed. You can stop the event propagation here, if you wish. If you don’t the event bubbles up to defaultFunction(). If the user clicks anywhere else defaultFunction() is also executed. This might be useful sometimes.

Setting document–wide event handlers is necessary in drag–and–drop scripts. Typically a mousedown event on a layer selects this layer and makes it respond to the mousemove event. Though the mousedown is usually registered on the layer to avoid browser bugs, both other event handlers must be document–wide.

Remember the First Law of Browserology: anything can happen, and it usually does when you’re least prepared for it. So it may happen that the user moves his mouse very wildly and the script doesn’t keep up so that the mouse is not over the layer any more.

  • If the onmousemove event handler is registered to the layer, the layer doesn’t react to the mouse movement any more, causing confusion.
  • If the onmouseup event handler is registered on the layer, this event isn’t caught either so that the layer keeps reacting to the mouse movements even after the user thinks he dropped the layer. This causes even more confusion.

So in this case event bubbling is very useful because registering your event handlers on document level makes sure they’re always executed.

Turning it off

But usually you want to turn all capturing and bubbling off to keep functions from interfering with each other. Besides, if your document structure is very complex (lots of nested tables and such) you may save system resources by turning off bubbling. The browser has to go through every single ancestor element of the event target to see if it has an event handler. Even if none are found, the search still takes time.

In the Microsoft model you must set the event’s cancelBubble property to true.

window.event.cancelBubble = true

In the W3C model you must call the event’s stopPropagation() method.

e.stopPropagation()

This stops all propagation of the event in the bubbling phase. For a complete cross-browser experience do

function doSomething(e)

{

	if (!e) var e = window.event;

	e.cancelBubble = true;

	if (e.stopPropagation) e.stopPropagation();

}

Setting the cancelBubble property in browsers that don’t support it doesn’t hurt. The browser shrugs and creates the property. Of course it doesn’t actually cancel the bubbling, but the assignment itself is safe.

currentTarget

As we’ve seen earlier, an event has a target or srcElement that contains a reference to the element the event happened on. In our example this is element2, since the user clicked on it.

It is very important to understand that during the capturing and bubbling phases (if any) this target does not change: it always remains a reference to element2.

But suppose we register these event handlers:

element1.onclick = doSomething;

element2.onclick = doSomething;

If the user clicks on element2 doSomething() is executed twice. But how do you know which HTML element is currently handling the event? target/srcElement don’t give a clue, they always refer to element2 since it is the original source of the event.

To solve this problem W3C has added the currentTarget property. It contains a reference to the HTML element the event is currently being handled by: exactly what we need. Unfortunately the Microsoft model doesn’t contain a similar property.

You can also use the this keyword. In the example above it refers to the HTML element the event is handled on, just like currentTarget.

Problems of the Microsoft model

But when you use the Microsoft event registration model the this keyword doesn’t refer to the HTML element. Combined with the lack of a currentTarget–like property in the Microsoft model, this means that if you do

element1.attachEvent('onclick',doSomething)

element2.attachEvent('onclick',doSomething)

you cannot know which HTML element currently handles the event. This is the most serious problem with the Microsoft event registration model and for me it’s reason enough never to use it, not even in IE/Win only applications.

I hope Microsoft will soon add a currentTarget–like property — or maybe even follow the standard? Web developers need this information.

Continue

If you wish to go through all event pages in order, you should now continue with the Mouse events page

http://www.quirksmode.org/js/events_order.html

에서 참조

 

Event order

See section 7D of the book.

Netscape 4 only supports event capturing, Explorer only supports event bubbling. Netscape 6 and Konqueror support both, while Opera and iCab support neither.

On the Introduction to events page I asked a question that at first sight seems incomprehensible: “If an element and one of its ancestors have an event handler for the same event, which one should fire first?” Not surprisingly, this depends on the browser.

The basic problem is very simple. Suppose you have a element inside an element

-----------------------------------

| element1                        |

|   -------------------------     |

|   |element2               |     |

|   -------------------------     |

|                                 |

-----------------------------------

and both have an onClick event handler. If the user clicks on element2 he causes a click event in both element1 and element2. But which event fires first? Which event handler should be executed first? What, in other words, is the event order?

Two models

Not surprisingly, back in the bad old days Netscape and Microsoft came to different conclusions.

  • Netscape said that the event on element1 takes place first. This is called event capturing.
  • Microsoft maintained that the event on element2 takes precedence. This is called event bubbling.

The two event orders are radically opposed. Explorer only supports event bubbling. Mozilla, Opera 7 and Konqueror support both. Older Opera’s and iCab support neither.

Event capturing

When you use event capturing

               | |

---------------| |-----------------

| element1     | |                |

|   -----------| |-----------     |

|   |element2   /          |     |

|   -------------------------     |

|        Event CAPTURING          |

-----------------------------------

the event handler of element1 fires first, the event handler of element2 fires last.

Event bubbling

When you use event bubbling

               / 

---------------| |-----------------

| element1     | |                |

|   -----------| |-----------     |

|   |element2  | |          |     |

|   -------------------------     |

|        Event BUBBLING           |

-----------------------------------

the event handler of element2 fires first, the event handler of element1 fires last.

W3C model

W3C has very sensibly decided to take a middle position in this struggle. Any event taking place in the W3C event model is first captured until it reaches the target element and then bubbles up again.

                 | |  / 

-----------------| |--| |-----------------

| element1       | |  | |                |

|   -------------| |--| |-----------     |

|   |element2     /  | |          |     |

|   --------------------------------     |

|        W3C event model                 |

------------------------------------------

You, the web developer, can choose whether to register an event handler in the capturing or in the bubbling phase. This is done through the addEventListener() method explained on the Advanced models page. If its last argument is true the event handler is set for the capturing phase, if it is false the event handler is set for the bubbling phase.

Suppose you do

element1.addEventListener('click',doSomething2,true)

element2.addEventListener('click',doSomething,false)

If the user clicks on element2 the following happens:

  1. The click event starts in the capturing phase. The event looks if any ancestor element of element2 has a onclick event handler for the capturing phase.
  2. The event finds one on element1. doSomething2() is executed.
  3. The event travels down to the target itself, no more event handlers for the capturing phase are found. The event moves to its bubbling phase and executes doSomething(), which is registered to element2 for the bubbling phase.
  4. The event travels upwards again and checks if any ancestor element of the target has an event handler for the bubbling phase. This is not the case, so nothing happens.

The reverse would be

element1.addEventListener('click',doSomething2,false)

element2.addEventListener('click',doSomething,false)

Now if the user clicks on element2 the following happens:

  1. The click event starts in the capturing phase. The event looks if any ancestor element of element2 has a onclick event handler for the capturing phase and doesn’t find any.
  2. The event travels down to the target itself. The event moves to its bubbling phase and executes doSomething(), which is registered to element2 for the bubbling phase.
  3. The event travels upwards again and checks if any ancestor element of the target has an event handler for the bubbling phase.
  4. The event finds one on element1. Now doSomething2() is executed.

Compatibility with traditional model

In the browsers that support the W3C DOM, a traditional event registration

element1.onclick = doSomething2;

is seen as a registration in the bubbling phase.

Use of event bubbling

Few web developers consciously use event capturing or bubbling. In Web pages as they are made today, it is simply not necessary to let a bubbling event be handled by several different event handlers. Users might get confused by several things happening after one mouse click, and usually you want to keep your event handling scripts separated. When the user clicks on an element, something happens, when he clicks on another element, something else happens.

Of course this might change in the future, and it’s good to have models available that are forward compatible. But the main practical use of event capturing and bubbling today is the registration of default functions.

It always happens

What you first need to understand is that event capturing or bubbling always happens. If you define a general onclick event handler for your entire document

document.onclick = doSomething;

if (document.captureEvents) document.captureEvents(Event.CLICK);

any click event on any element in the document will eventually bubble up to the document and thus fire this general event handler. Only when a previous event handling script explicitly orders the event to stop bubbling, it will not propagate to the document.

Uses

Because any event ends up on the document, default event handlers become possible. Suppose you have this page:

------------------------------------

| document                         |

|   ---------------  ------------  |

|   | element1    |  | element2 |  |

|   ---------------  ------------  |

|                                  |

------------------------------------



element1.onclick = doSomething;

element2.onclick = doSomething;

document.onclick = defaultFunction;

Now if the user clicks on element1 or 2, doSomething() is executed. You can stop the event propagation here, if you wish. If you don’t the event bubbles up to defaultFunction(). If the user clicks anywhere else defaultFunction() is also executed. This might be useful sometimes.

Setting document–wide event handlers is necessary in drag–and–drop scripts. Typically a mousedown event on a layer selects this layer and makes it respond to the mousemove event. Though the mousedown is usually registered on the layer to avoid browser bugs, both other event handlers must be document–wide.

Remember the First Law of Browserology: anything can happen, and it usually does when you’re least prepared for it. So it may happen that the user moves his mouse very wildly and the script doesn’t keep up so that the mouse is not over the layer any more.

  • If the onmousemove event handler is registered to the layer, the layer doesn’t react to the mouse movement any more, causing confusion.
  • If the onmouseup event handler is registered on the layer, this event isn’t caught either so that the layer keeps reacting to the mouse movements even after the user thinks he dropped the layer. This causes even more confusion.

So in this case event bubbling is very useful because registering your event handlers on document level makes sure they’re always executed.

Turning it off

But usually you want to turn all capturing and bubbling off to keep functions from interfering with each other. Besides, if your document structure is very complex (lots of nested tables and such) you may save system resources by turning off bubbling. The browser has to go through every single ancestor element of the event target to see if it has an event handler. Even if none are found, the search still takes time.

In the Microsoft model you must set the event’s cancelBubble property to true.

window.event.cancelBubble = true

In the W3C model you must call the event’s stopPropagation() method.

e.stopPropagation()

This stops all propagation of the event in the bubbling phase. For a complete cross-browser experience do

function doSomething(e)

{

	if (!e) var e = window.event;

	e.cancelBubble = true;

	if (e.stopPropagation) e.stopPropagation();

}

Setting the cancelBubble property in browsers that don’t support it doesn’t hurt. The browser shrugs and creates the property. Of course it doesn’t actually cancel the bubbling, but the assignment itself is safe.

currentTarget

As we’ve seen earlier, an event has a target or srcElement that contains a reference to the element the event happened on. In our example this is element2, since the user clicked on it.

It is very important to understand that during the capturing and bubbling phases (if any) this target does not change: it always remains a reference to element2.

But suppose we register these event handlers:

element1.onclick = doSomething;

element2.onclick = doSomething;

If the user clicks on element2 doSomething() is executed twice. But how do you know which HTML element is currently handling the event? target/srcElement don’t give a clue, they always refer to element2 since it is the original source of the event.

To solve this problem W3C has added the currentTarget property. It contains a reference to the HTML element the event is currently being handled by: exactly what we need. Unfortunately the Microsoft model doesn’t contain a similar property.

You can also use the this keyword. In the example above it refers to the HTML element the event is handled on, just like currentTarget.

Problems of the Microsoft model

But when you use the Microsoft event registration model the this keyword doesn’t refer to the HTML element. Combined with the lack of a currentTarget–like property in the Microsoft model, this means that if you do

element1.attachEvent('onclick',doSomething)

element2.attachEvent('onclick',doSomething)

you cannot know which HTML element currently handles the event. This is the most serious problem with the Microsoft event registration model and for me it’s reason enough never to use it, not even in IE/Win only applications.

I hope Microsoft will soon add a currentTarget–like property — or maybe even follow the standard? Web developers need this information.

Continue

If you wish to go through all event pages in order, you should now continue with the Mouse events page

http://stackoverflow.com/questions/4616694/what-is-event-bubbling-and-capturing

에서 참조

Event bubbling and capturing are two ways of event propagation in HTML DOM.

In bubbling the event is first captured and handled by the inner most element and then propagated to outer elements.

In capturing the event is first captured by the outer most element and propagated to the inner most element.

During the time of Netscape browser they were advocates of event capturing and Microsoft was from event bubbling school.

Both are part of the w3 standard. As per the standard first the event will capture it till it reaches the target then it will bubble up to the outer most element.

IE uses only event bubbling where as firefox supports both bubbling and capturing.

We can use the addEventListener(type, listener, useCapture) to register event handlers for bubbling and capturing phases. To use the capturing phase event handling pass the third argument as true.

Only event bubbling model is supported by all the major browsers. So if you are going to use event capturing still you need to handle event bubbling for IE. So it will easier to use event bubbling instead of capturing.

If you take this structure and assume that a click event has happed in the li element.

In capturing model the event will be handled by the div first(click event handlers in the div will fire first) then in the ul then at the last in the target element li.

In bubbling model it is the opposite. In this model the event will be first handled by the li first and the ul and at the last by the div element.

You can find more informations from the below sites.
Event Order
addEventListener
Events Advanced

http://stackoverflow.com/questions/4616694/what-is-event-bubbling-and-capturing

에서 참조

Event bubbling and capturing are two ways of event propagation in HTML DOM.

In bubbling the event is first captured and handled by the inner most element and then propagated to outer elements.

In capturing the event is first captured by the outer most element and propagated to the inner most element.

During the time of Netscape browser they were advocates of event capturing and Microsoft was from event bubbling school.

Both are part of the w3 standard. As per the standard first the event will capture it till it reaches the target then it will bubble up to the outer most element.

IE uses only event bubbling where as firefox supports both bubbling and capturing.

We can use the addEventListener(type, listener, useCapture) to register event handlers for bubbling and capturing phases. To use the capturing phase event handling pass the third argument as true.

Only event bubbling model is supported by all the major browsers. So if you are going to use event capturing still you need to handle event bubbling for IE. So it will easier to use event bubbling instead of capturing.

If you take this structure and assume that a click event has happed in the li element.

In capturing model the event will be handled by the div first(click event handlers in the div will fire first) then in the ul then at the last in the target element li.

In bubbling model it is the opposite. In this model the event will be first handled by the li first and the ul and at the last by the div element.

You can find more informations from the below sites.
Event Order
addEventListener
Events Advanced

Event Capture and Bubbling

The DOM has two ways for objects to detect events: from the top down, and from the bottom up. The first method is known as event capture, the second is called event bubbling.

Event Capture

diagram showing arrows moving downwards

Let’s say that your document contains a<div>which contains a<p>which contains an<img>. Further, let’s say you’ve added an event listener to all of them. When a user clicks on the image, amouseclickevent occurs.

Even though the user clicked the image, the image doesn’t get the event first. Instead, the event listener attached to the document grabs the event first and processes it. (That is, it captures the event before it gets to its intended target.) The event is then passed down to the <div>’s event listener. The event then goes to the <p>, and finally to the <img>. That is, all of the clicked-on object’s “ancestors” higher up in the document capture the event for processing before sending it down the chain to its intended target. You can try event capture in a pop-up window. (This only works in Mozilla.)

Event Bubbling

diagram showing arrows moving upwards

Now let’s look at the same situation from the inside out. You have an <img>inside a <p>, which is inside a <div>, which is inside your document. When a user clicks the image, this time the events rise like a bubble in a glass of water. The click’s original target, the <img>, gets to see the event first, and then passes it upwards to the <p>for further processing, which passes it on to the <div>, which finally passes it up to the document. You can try event bubbling in a pop-up window. (This only works in Mozilla.)

Here are the relevant parts of the source code for both demos.