Bubbling and capturing

, then we’ll see 3 alerts: p -> div -> form. The process is called “bubbling”, because events “bubble” from the inner element up through parents like a bubble in the water.

event.target

A handler on a parent element can always get the details about where it actually happened. The most deeply nested element that caused the event is called a target element, accessible as event.target. Note the differences from this (=event.currentTarget): - event.target – is the “target” element that initiated the event, it doesn’t change through the bubbling process. - this – is the “current” element, the one that has a currently running handler on it. For instance, if we have a single handler form.onclick, then it can “catch” all clicks inside the form. No matter where the click happened, it bubbles up to and runs the handler. In form.onclick handler: - this (=event.currentTarget) is the element, because the handler runs on it. - event.target is the actual element inside the form that was clicked. Check it out: [codetabs height=220 src=“bubble-target”] It’s possible that event.target could equal this – it happens when the click is made directly on the element.

Stopping bubbling

A bubbling event goes from the target element straight up. Normally it goes upwards till , and then to document object, and some events even reach window, calling all handlers on the path. But any handler may decide that the event has been fully processed and stop the bubbling. The method for it is event.stopPropagation(). For instance, here body.onclick doesn’t work if you click on :

Capturing

There’s another phase of event processing called “capturing”. It is rarely used in real code, but sometimes can be useful. The standard DOM Events describes 3 phases of event propagation: 1. Capturing phase – the event goes down to the element. 2. Target phase – the event reached the target element. 3. Bubbling phase – the event bubbles up from the element. Here’s the picture, taken from the specification, of the capturing (1), target (2) and bubbling (3) phases for a click event on a inside a table: That is: for a click on the event first goes through the ancestors chain down to the element (capturing phase), then it reaches the target and triggers there (target phase), and then it goes up (bubbling phase), calling handlers on its way. Until now, we only talked about bubbling, because the capturing phase is rarely used. In fact, the capturing phase was invisible for us, because handlers added using on-property or using HTML attributes or using two-argument addEventListener(event, handler) don’t know anything about capturing, they only run on the 2nd and 3rd phases. To catch an event on the capturing phase, we need to set the handler capture option to true: There are two possible values of the capture option: - If it’s false (default), then the handler is set on the bubbling phase. - If it’s true, then the handler is set on the capturing phase. Note that while formally there are 3 phases, the 2nd phase (“target phase”: the event reached the element) is not handled separately: handlers on both capturing and bubbling phases trigger at that phase. Let’s see both capturing and bubbling in action: The code sets click handlers on every element in the document to see which ones are working. If you click on

, then the sequence is: 1. HTML -> BODY -> FORM -> DIV -> P (capturing phase, the first listener): 2. P -> DIV -> FORM -> BODY -> HTML (bubbling phase, the second listener). Please note, the P shows up twice, because we’ve set two listeners: capturing and bubbling. The target triggers at the end of the first and at the beginning of the second phase. There’s a property event.eventPhase that tells us the number of the phase on which the event was caught. But it’s rarely used, because we usually know it in the handler. elem.addEventListener(“click”, e => alert(1)); // guaranteed to trigger first elem.addEventListener(“click”, e => alert(2));

Summary

When an event happens – the most nested element where it happens gets labeled as the “target element” (event.target). - Then the event moves down from the document root to event.target, calling handlers assigned with addEventListener(…, true) on the way (true is a shorthand for {capture: true}). - Then handlers are called on the target element itself. - Then the event bubbles up from event.target to the root, calling handlers assigned using on, HTML attributes and addEventListener without the 3rd argument or with the 3rd argument false/{capture:false}. Each handler can access event object properties: - event.target – the deepest element that originated the event. - event.currentTarget (=this) – the current element that handles the event (the one that has the handler on it) - event.eventPhase – the current phase (capturing=1, target=2, bubbling=3). Any event handler can stop the event by calling event.stopPropagation(), but that’s not recommended, because we can’t really be sure we won’t need it above, maybe for completely different things. The capturing phase is used very rarely, usually we handle events on bubbling. And there’s a logical explanation for that. In real world, when an accident happens, local authorities react first. They know best the area where it happened. Then higher-level authorities if needed. The same for event handlers. The code that set the handler on a particular element knows maximum details about the element and what it does. A handler on a particular may be suited for that exactly , it knows everything about it, so it should get the chance first. Then its immediate parent also knows about the context, but a little bit less, and so on till the very top element that handles general concepts and runs the last one. Bubbling and capturing lay the foundation for “event delegation” – an extremely powerful event handling pattern that we study in the next chapter.

Copy Code

<div onclick="alert('The handler!')">
  <em>If you click on <code>EM</code>, the handler on <code>DIV</code> runs.</em>
</div>