On Wed, Feb 23, 2011 at 1:54 AM, RobG <[email protected]> wrote: > > > On Feb 22, 9:45 pm, Diego Perini <[email protected]> wrote: >> On Tue, Feb 22, 2011 at 3:30 AM, RobG <[email protected]> wrote: >> >> > On Feb 22, 12:09 pm, Diego Perini <[email protected]> wrote: >> >> Mark, >> >> use event "delegation" and only setup one listener on the "document" >> >> for the type of event you want notifications. >> >> > And for those events that don't bubble? >> >> In older browsers like IE only few events do not bubble and those are >> the events bound to form controls (submit/reset/change/focus/blur). > > You mean in *all* browsers that implement what the W3C calls "HTML > event types". >
Yes ! That's how I should have written it :) However the statement I wrote above is a bit confused and does not represent exactly what I wanted to say. What I wanted to add (and failed to explain) is that even if these events do not "bubble" in any browser, it is possible to "capture" them in W3C DOM2 compliant browsers while in IE < 9 this is not directly available. > <URL: > http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-htmlevents >> > > > Event delegation is a good strategy where it can be used to replace > multiple (usually identical or very similar, but not always) listeners > on a group of elements. But it can be inefficient and is not suitable > where only a few listeners are required. > > Placing a single listener on the document to handle all events can > create more comlexity and issues than it solves. It may be better to > use an element that is a closer ancestor of the subject elements, or > just attach listeners directly. The solution should fit the > requirements, be robust and easily maintainable. > True ! By attaching events to a closer ancestor there is less propagation going on in the browser engines, also that's something that happens very fast internally (it is not Javascript code). However this pattern creates a bottleneck since extra code is necessary to achieve the final objective: - a working implementation of "DOMContentLoaded", missing in IE < 9 - a working implementation of "querySelectorAll, missing in IE < 9 These parts introduces unnecessary delays and block other script execution until the wanted behavior has been initialized and applied. So the alternative to "delegation" forces developers having to wait for a "DOMContentLoaded" (or similar) event to be able to collect all the elements and then loop over the collection to add event listeners to each of the elements found in the collection. In contrast "delegation" can start as soon as javascript can execute without any extra code requirements and especially without either delaying nor blocking other scripts (except for the function handler registration (DOM2) or property assignment (DOM 0). > [...] > >> If a complete cross-browser implementation is needed you can use my >> NWEvents project > > Looks interesting, I'll have a play. > First thing I will need to do in NWEvents is split the big file in three parts (standard, delegation, notifications). It would like the users be able to only load the parts they really need in their applications. Look forward to suggestions and/or corrections to shape it up :) -- Diego > -- > Rob > > -- > To view archived discussions from the original JSMentors Mailman list: > http://www.mail-archive.com/[email protected]/ > > To search via a non-Google archive, visit here: > http://www.mail-archive.com/[email protected]/ > > To unsubscribe from this group, send email to > [email protected] > -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
