Mike, what I normally need is let the CSS selector specify on what elements I want lo listen for event and not have that embedded by default (forced) in the plugins or core.
For example I prefer to be able to fully use and specify CSS selector like these in the delegation method: '#nav' listening on one element in the page '#nav *' listening on elements children of #nav '#nav, #nav *' listening on #nav itself and all of its children so the developer can decide on which elements to fire only through specific CSS selectors. For simpler tasks the .is() will be enough for most needs, for the above, I believe we will need find() or something still more powerful. Having the choice to delegate events for "not yet rendered" elements will greatly improve the "early page enlivenment" capabilities of jQuery. The NWEvents code above is doing that, and is emulating the bubbling for those events that do not bubble which makes it a bit more generic. In my simple tests I can perfectly handle also mouseover/mouseout and mousemove event delegation, if handlers yield enough time for that. :-) It would be nice if you could have a look at it and adjust current proposal for jQuery delegation if deemed adequate. Please tell if my needs are so different... -- Diego On 10 Ott, 19:09, "mike.helgeson" <[EMAIL PROTECTED]> wrote: > So I put out a plugin today to acheive all of the goals stated > previously: > > - Data, event data as is currently supported in the event system > - Bubbling, starting with event.target, and traversing up the parent > tree to match the delegate selector > - Canceling default event behavior, parent tree-walking, other > delegate handlers on the same element > - Intelligent Removal, being able to remove all delegates, remove > delegates by event type (or namespace), event type and selector (and > sometimes handler) > > Please take a look and discuss how to best implement delegation in the > core. There are a lot of plugins out there which solve the same > problem. Ariel has "listen" and "intercept", Jorn has "delegate" in > his "validation," plugin to name a few... perhaps the best features of > each should be considered. > > http://plugins.jquery.com/project/delegatehttp://blog.threedubmedia.com/2008/10/jquerydelegate.htmlhttp://threedubmedia.com/demo/delegate/ > > On Aug 25, 10:51 am, "mike.helgeson" <[EMAIL PROTECTED]> wrote: > > > Event delegation is on the roadmap for 1.3 > > >http://docs.jquery.com/JQuery_1.3_Roadmap > > > My question is: Who is taking the lead on this particular task? > > I have some thoughts and solutions for event delegation that are a > > little more robust than Joern's delegate plugin. For the solution that > > makes it into the core, I would expect to see the following features > > and functionality for event delegation: > > > - Data, event data as is currently supported in the event system > > - Bubbling, starting with event.target, and traversing up the parent > > tree to match the delegate selector > > - Canceling default event behavior, parent tree-walking, other > > delegate handlers on the same element > > - Intelligent Removal, being able to remove all delegates, remove > > delegates by event type (or namespace), event type and selector (and > > sometimes handler) > > > I have some code I can share with anyone who is interested, it is a > > first pass at all of these features. I would also like to know the > > thoughts and expectations of other developers who have ever used event > > delegation, especially around cancellation. > > > -mike --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~----------~----~----~----~------~----~------~--~---
