So far we've been able to respond to user events, but there's an interesting thing

happening behind the scenes when an event takes place.

An event received by an element doesn't stop with that one element,

that event moves to other elements, the parent and other ancestors of the element.

This is called event bubbling, now I know this sounds funny as if they

percolate like coffee, but in a sense that's exactly what's happening.

So let's take a look at the drawing of the DOM again.

Look at this li element at the bottom.

Let's say a user clicks on the list item, the list item receives the click event but

immediately after, its parent, the UL element, receives the same event.

This means that if you added a click event handler to the ul,

that event handler function would run as well.

In other words, clicking on the li is also clicking on the ul.

And it doesn't stop there.

Next, the ul's parent element, the body, receives the same event, and

the event keeps traveling until it gets to the top most element on the tree.

Likewise, if the h1 element receives an event,

that event travels to the body element and finally to the root as well.

So events rise up like bubbles through the DOM tree,

which is where that term bubble comes from.

What bubbling allows us to do is listen for events on ancestor elements,

for example, if we set a click handler on the body,

our callback will trigger whenever any of its children are clicked.

So if any of the list items, the paragraph,

or headline elements are clicked, the callback will trigger in this example.

Event bubbling might not seem immediately useful,

but in fact this will allow us to write much more powerful handlers.

For example, we can use this to replace all the handlers we're attaching to

each list item with just one pair of handlers on a parent element.

I'll show you how.

In the previous video, we wrote code to loop through other list items and

attach individual handlers to each item.

Well, with bubbling we could just do this once on an ancestor of these list items

and all events would still be caught and handled as they bubble up.

This would make our code much simpler to implement

as well as using less of the browsers memory for all those individual listeners.

And there's one more benefit, since the handlers are not bound

to individual list items, any item can be added after the listener has run and

no additional setup is required for that item events to be handled.

So let's switch back to index.html and

look at where we want to attach our behavior.

So when you're trying to decide which element to use, remember,

it has to be an ancestor of the target elements, in other words, a tag or

element that wraps around or contains the element you're interested in.

For example, setting the event listener on the headline

would do no good because it's a sibling of an ancestor, not in the direct line.

Also think about what element won't ever be removed from the DOM.

For example, the body element will almost never be removed, but for the sake

of performance it's usually best to get as close to the targets as possible.

So let's attach it to the div with the class list, which contains the whole list.

I'm going to switch back to app.js, and

up top, we already have a reference to the list div element for

our other handler that hides and unhides the list, so let's reuse it.

So first, I'll remove just the loop and this list items selection, and

unindent these handlers.

Then, I'll place each event listener on listDiv, rather than listItems[i].

But looking at the inside of these callback functions,

there's a problem, when events fire on listDiv,

how do we know which list item is triggering the event?

The only thing we have is a reference to the entire div.

So in the next video I'll show you how to solve that problem using what's called

the event object.

See you there.