# Event delegation Capturing and bubbling allow us to implement one of most powerful event handling patterns called *event delegation*. The idea is that if we have a lot of elements handled in a similar way, then instead of assigning a handler to each of them -- we put a single handler on their common ancestor. In the handler we get `event.target`, see where the event actually happened and handle it. Let's see an example -- the [Ba-Gua diagram](http://en.wikipedia.org/wiki/Ba_gua) reflecting the ancient Chinese philosophy. Here it is: [iframe height=350 src="bagua" edit link] The HTML is like this: ```html
Bagua Chart: Direction, Element, Color, Meaning | ||
---|---|---|
Northwest Metal Silver Elders |
... | ... |
` dynamically at any time and the highlighting will still work. Still, there's a drawback. The click may occur not on the ` | `, but inside it. In our case if we take a look inside the HTML, we can see nested tags inside ` | `, like ``:
```html
*!*
Northwest
*/!*
...
|
```
Naturally, if a click happens on that `` then it becomes the value of `event.target`.

In the handler `table.onclick` we should take such `event.target` and find out whether the click was inside `` or not.
Here's the improved code:
```js
table.onclick = function(event) {
let td = event.target.closest('td'); // (1)
if (!td) return; // (2)
if (!table.contains(td)) return; // (3)
highlight(td); // (4)
};
```
Explanations:
1. The method `elem.closest(selector)` returns the nearest ancestor that matches the selector. In our case we look for ` | ` on the way up from the source element.
2. If `event.target` is not inside any ` | `, then the call returns `null`, and we don't have to do anything.
3. In case of nested tables, `event.target` may be a ` | ` lying outside of the current table. So we check if that's actually *our table's* ` | `.
4. And, if it's so, then highlight it.
As the result, we have a fast, efficient highlighting code, that doesn't care about the total number of ` | ` in the table.
## Delegation example: actions in markup
There are other uses for event delegation.
Let's say, we want to make a menu with buttons "Save", "Load", "Search" and so on. And there's an object with methods `save`, `load`, `search`... How to match them?
The first idea may be to assign a separate handler to each button. But there's a more elegant solution. We can add a handler for the whole menu and `data-action` attributes for buttons that has the method to call:
```html
```
The handler reads the attribute and executes the method. Take a look at the working example:
```html autorun height=60 run
|
```
Please note that `this.onClick` is bound to `this` in `(*)`. That's important, because otherwise `this` inside it would reference the DOM element (`elem`), not the `Menu` object, and `this[action]` would not be what we need.
So, what the delegation gives us here?
```compare
+ We don't need to write the code to assign a handler to each button. Just make a method and put it in the markup.
+ The HTML structure is flexible, we can add/remove buttons at any time.
```
We could also use classes `.action-save`, `.action-load`, but an attribute `data-action` is better semantically. And we can use it in CSS rules too.
## The "behavior" pattern
We can also use event delegation to add "behaviors" to elements *declaratively*, with special attributes and classes.
The pattern has two parts:
1. We add a custom attribute to an element that describes its behavior.
2. A document-wide handler tracks events, and if an event happens on an attributed element -- performs the action.
### Behavior: Counter
For instance, here the attribute `data-counter` adds a behavior: "increase value on click" to buttons:
```html run autorun height=60
Counter:
One more counter:
```
If we click a button -- its value is increased. Not buttons, but the general approach is important here.
There can be as many attributes with `data-counter` as we want. We can add new ones to HTML at any moment. Using the event delegation we "extended" HTML, added an attribute that describes a new behavior.
```warn header="For document-level handlers -- always `addEventListener`"
When we assign an event handler to the `document` object, we should always use `addEventListener`, not `document.on |