Sounds great! I think it is a good idea to collaborate about this and together reach the best solution! I’ll talk with the team about this.

You may see my NWEvents at work in an event delegation test here:

http://javascript.nwbox.com/NWEvents/delegates.html

Sorry for the fuzziness of the sample, it was just a combined test for all the quirks I found during development and to stress my NWMatcher selector engine mixed in with event delegation.

The best thing is that I even don’t need an “onload” or an “onReady” event to attach functionality to the page, this avoids the problem of “early page enlivenment” you talked about in another post.

Well since you already have a nice Event Manager it shouldn’t be too difficult to implement the “Light” part of event delegation, it will prove extremely useful in a project like DOMAssistant. And since I see you have built a very fast selector engine too it will combine perfectly.

Let me know, I will be happy to give info on my code. You can grab the latest versions from Google Code SVN.

Diego Perini

I think it’s important to apply the events at the best place in the HTML hierarchy; this is, of course, heavily context-dependent. The body might be suitable in some cases, but generally I think it’s overkill. Generally, I think it’s ok, for instance, to have one event for the navigation, one for the content etc.

It’s a delicate balance which can result in slower times, if it’s applied too high up in a page with a lot of elements. Basically, it’s about being pragmatic.

Morgan,

Good to see that we’re on the same page! I actually linked to Chris’ example above, where he does event delegation with YUI.

One of the very nice aspects of using event delegation, which is somewhat understated in the post, is that your code also becomes a lot easier to maintain… even more so, when compared to inline event handlers.

It does take a little while to wrap your head around, but once you’ve got a firm grasp of the technique, the clarity of your code will improve quite a lot, and updating it will become easier.

Oh, and not to forget … using event delegates, makes for happy Ajax development, where you can assign a delegate on a parent element, and just replace it’s content with Ajax, and all you spiffy event based javascripty goodness just works

Chris Heilmann created a small experiment a couple of years ago, that has inspired me to change how I think about events, when doing scripting for browsers.

http://icant.co.uk/sandbox/eventdelegation/

Is there no chance of things ever getting slower because of ED? If you put every onclick-event on the body instead of the actual elements that users should click, won’t it take a sec or so to sort out which callback to run whereas if the event was set on the actual element being clicked it would simply run it straight away?

I’m curious because I’m using my ImgZoom plug-in (which uses ED) on a site that already has loads of other ED (up to the same (body) elment) and when I click an image now it takes a sec or so before it shows up whereas on my demo-page you hardly got time to blink.

Absolutely, with more advanced HTML or elements with margin etc, you do need to do some DOM traversing. DOMAssistant does exclude text nodes automatically, but to make it more efficient for advanced scenarios, I guess doing a sort of selector on the target and possible parent elements might be a good solution.

Tommy,

Peter-Paul Koch has written an article about event delegation with the focus and blur events, which is based on the techniques described by Curtis above. However, it would be nice to have event bubbling of all events, I think. Especially a lot of form scripting could be vastly improved.

And thanks for the congratulation, I’ll cover that in my next post. And congratulations to you for spot #46.

dAN,

Glad you liked it!

BTW, congratulations to Robert for making #19 on Computer Sweden’s list of Sweden’s 75 top developers!

dAN

Only this weekend I was writing what I expected to be a simple script for a page with 60(!) input fields where I needed things to happen each time one of those fields lost keyboard focus. I tried to use an event listener for the blur event on the parent, but it didn’t work. It took me a while to realise that blur events don’t bubble.

?? ???? ?? ?? event delegation….

It’s easy to workaround by either walking up the DOM tree using a while loop and parentNode (while being careful to go further then you need of course), on in this particular case, since you are only interested in actions on the anchor tag, simply add a conditional to check evt.eventTarget’s node name (assuming DOMAssistant resolves events from text elements, which it appears it does do).