Is preventDefault and stopPropagation jQuery or plain js methods?
Also, do you know of a good source that explains event bubbling/capturing?
They are part of the DOM API, and so are available in plain JS within the browser (note that stopPropagation was not available in IE until version 9).
There's a good overview here: http://stackoverflow.com/questions/4616694/what-is-event-bubbling-and-capturing, which also provides some links to further information. Probably the most important thing to know is that event bubbling is the model that is supported by all the major browsers.
So from that article and others I've read today I think I understand that the w3 standard is to do both the capturing and bubbling phase? So for every event it's first handled in the outer most element in the DOM, travels down to the element clicked on, then back up to the outer most element?
Yeah, that's my understanding of it.
cool, thanks. it's becoming clearer.
Have you ever taken advantage of event bubbling in practice?
Or can you describe details of how this would be advantageous in the real world?
I read about an example of a click event being added to a table row. But the script might later insert more rows to that table and those new rows would need that same event handler. So rather than individually adding/maintaining handlers/listeners to each row, a handler was attached to the table. But I missed how this is takes advantage of event bubbling.
Yes, I've used it in exactly the sort of scenario you've just described, with a dynamically populated list of search results. Rather than attaching a click event handler to a link on each row, I took advantage of event bubbling by attaching the handler to the list container element.
There are two advantages to this:
- It performs better vs large numbers of separate handlers, and
- It will catch events that bubble from elements that were added to the page after you've attached the handler.
2 makes sense to me.
So following your example:
I might want to react to clicking any link, but I could attach an event handler to the <ul> ?
Then how would my code know which link was clicked?
That's right, although interestingly I was just looking up a reference for that and I came across this post which claims that although delegation is more efficient to set up, binding event handlers directly to each element is more efficient (CPU-wise) when triggering than waiting for the event to bubble up the DOM.
The event object has a
target property which contains the element that triggered the event (see: https://developer.mozilla.org/en-US/docs/Web/API/event.target).
What's delagation? Or what 's the difference between delegation and binding?
Binding is about every element having the decision power and representing itself, when it comes to events.
Delegation defines a mandated proxy to handle the events in the name of a group of elements. It's still binding but on different, higher levels.
Binding may take longer to set up before being ready to execute and can get difficult to manage in code. Delegation may take longer to execute but it's easier to maintain.
Think of "binding vs. delegation" as of "event binding vs. event binding delegation based on event bubbling effect".
If you take a needle and poke your self in the little finger with it, event bubbling will make the information in the form of pain data to travel along your arm, upper body, up to your brain.
If you click a link which is inside a list element, the event will bubble up the li>ul>...>body>html>document>window route. This makes brain delegation possible, and it will make you slap yourself in the face for playing around with needles. In the theory anyway. In reality you could just delegate/capture the click event to the ul instead of binding click events on each li, all the while contemplating for things to do, other than torturing yourself.
ok, so event binding is more of a one to one basis. I bind 1 event handler to 1 element?
While event delegation is like 1 to many. Where say 1 event handler is bound to a ul but it's fired off from 1 or many links in <li>s?
Yes. For meaningful interaction you have to bind/override event behavior to the elements. By default, when an event fires, (almost) nothing happens. It's just a question on where exactly to handle the events, right there or somewhere higher up the chain.
Event delegation is like having a general for an army. Everybody is just reporting, the decision is made somewhere up the chain. Event delegation is also short for event delegation binding, since the general has to be named at same point.
All this is because an event travels (bubbles) naturally up the parent elements until it reaches the highest level, the parent of all elements. This can be prevented though, can be stopped at the parent element of your choosing.
This topic is now closed. New replies are no longer allowed.