`, but also runs if you click any nested tag like `` or ``: ```html autorun height=60 If you click on EM, the handler on DIV runs. ``` Isn't it a bit strange? Why the handler on `` runs if the actual click was on ``? ## Bubbling The bubbling principle is simple. **When an event happens on an element, it first runs the handlers on it, then on its parent, then all the way up on other ancestors.** Let's say, we have 3 nested elements `FORM > DIV > P` with a handler on each of them: ```html run autorun FORM DIV P ``` A click on the inner `` first runs `onclick`: 1. On that ` `. 2. Then on the outer ` `. 3. Then on the outer ``. 4. And so on upwards till the `document` object. ![](event-order-bubbling.png) So if we click on ``, 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. ```warn header="*Almost* all events bubble." The key word in this phrase is "almost". For instance, a `focus` event does not bubble. There are other examples too, we'll meet them. But still it's an exception, rather than a rule, most events do bubble. ``` ## 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 concrete element inside the form that actually was clicked. Check it out: [codetabs height=220 src="bubble-target"] It's possible that `event.target` equals `this` -- 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 ` ``` ```smart header="event.stopImmediatePropagation()" If an element has multiple event handlers on a single event, then even if one of them stops the bubbling, the other ones still execute. In other words, `event.stopPropagation()` stops the move upwards, but on the current element all other handlers will run. To stop the bubbling and prevent handlers on the current element from running, there's a method `event.stopImmediatePropagation()`. After it no other handlers execute. ``` ```warn header="Don't stop bubbling without a need!" Bubbling is convenient. Don't stop it without a real need: obvious and architecturally well-thought. Sometimes `event.stopPropagation()` creates hidden pitfalls that later may become problems. For instance: 1. We create a nested menu. Each submenu handles clicks on its elements and calls `stopPropagation` so that outer menu don't trigger. 2. Later we decide to catch clicks on the whole window, to track users' behavior (where people click). Some analytic systems do that. Usually the code uses `document.addEventListener('click'…)` to catch all clicks. 3. Our analytic won't work over the area where clicks are stopped by `stopPropagation`. We've got a "dead zone". There's usually no real need to prevent the bubbling. A task that seemingly requires that may be solved by other means. One of them is to use custom events, we'll cover them later. Also we can write our data into the `event` object in one handler and read it in another one, so we can pass to handlers on parents information about the processing below. ``` ## 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](http://www.w3.org/TR/DOM-Level-3-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 of a click on `` inside a table, taken from the specification: ![](eventflow.png) That is: for a click on `` the event first goes through the ancestors chain down to the element (capturing), then it reaches the target, and then it goes up (bubbles), calling handlers on its way. **Before we only talked about bubbling, because the capturing phase is rarely used. Normally it is invisible to us.** Handlers added using `on`-property or using HTML attributes or using `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 3rd argument of `addEventListener` to `true`. There are two possible values for that optional last argument: - 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. If one puts capturing and bubbling handlers on the target element, the capture handler triggers last in the capturing phase and the bubble handler triggers first in the bubbling phase. Let's see it in action: ```html run autorun height=140 edit FORM DIV P ``` 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), and then: 2. `P` -> `DIV` -> `FORM` -> `BODY` -> `HTML` (bubbling phase, the second listener). Please note that `P` shows up two times: at the end of capturing and at the start of bubbling. 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. ## Summary The event handling process: - When an event happens -- the most nested element where it happens gets labeled as the "target element" (`event.target`). - Then the event first moves from the document root down the `event.target`, calling handlers assigned with `addEventListener(...., true)` on the way. - Then the event moves from `event.target` up to the root, calling handlers assigned using `on` and `addEventListener` without the 3rd argument or with the 3rd argument `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, 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 logic behind 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. Bubbling and capturing lay the foundation for "event delegation" -- an extremely powerful event handling pattern that we study in the next chapter.