Mike, I am happy to see some of the questions/points you make above were already answered here:
http://groups.google.com/group/jquery-dev/browse_thread/thread/ddb5387f309e8b60/905344e61030b9ca?lnk=gst&q=event+delegation+document+order#905344e61030b9ca At that time, I was answered that "document order" had nothing to do with delegation and/or events bubbling/capturing in general, I hope you now have another view of it...and understand why John have added that. I have offered in the past both solutions to the specific hidden problems of "document ordered" results set and related bubbling/ capturing in delegation. I had no luck at that time but that doesn't make me desist...because I care. I just hope you will have a look at the mentioned projects maybe with some suggestion on why this may have not been taken in too much consideration then. Anyway I see everything is going to that, John cleverly implemented a powerful Sizzle to solve that, then with suggestions he implemented "document order", have discarded (temporarily) the caching system but I know that when he see it working he may think back to it again, now Mike points out that bubbling does not work because of not always ordered results sets. Good findings...you left out the NWMatcher / NWEvents, the special "match()" method really suited for delegations tasks etc. Have you ever...ever..given a look there to see if some bit of what you say is already solved or slightly suit to your needs ? Did you find the problems you talk about in NWEvents ? Hey...I excuse myself to be a bit rude this time but can't we just have a look at existing and stable code and implement the good of it in jQuery the jQuery way. I already solved how to delegate all forms events a cross browser way and be able to attach them even before the body tag exists...And I have the "match()" event to avoid all the step you mentioned to see if ONE element matches the selector. With that method no speed problems...repeat...no speed problems and cross- browser. I really do not pretend my project is what the future jQuery implementation should be, anyway I have no doubt that the implementation of the W3C specs are there, the IE emulation things everybody is looking at are already there, and especially the context things you are telling is important is also part of the capabilities introduced by my project with many other. The "data" thing is still missing there but I have had it in my development trunk with other goodies for a while (testing them). The things that are missing to be plug'n play for jQuery are just a few thinks away from John, I imagine he want to do it himself as he did with Sizzle and surely improve on that too. ;-) I hope the "document order" thorn I have been to John helped jQuery differentiate in spec compliance and usability from other frameworks. Now live events can have a life. With respect for the big advances I see here both in code and thinking. jQuery is at least one year ahead the competition on these basics core functionalities of frameworks. Diego Perini On 17 Feb, 00:05, "mike.helgeson" <mike.helge...@gmail.com> wrote: > - The selector must be run, before the event handler is bound... this > seems less than ideal, if a large number of DOM elements already exist > > - Always binds/listens to the document. My biggest hesitation with > using live for delegation, is that there is no way to control the > listener, it is always the document. It should at least use the jquery > collection's context. > > - Functionality is private... would like to expose the internal > functions "liveConvert" and "liveHandler" to enable a plugin to > leverage some of the features. > > - Can't attach data to handlers the way you could using "bind" > > - Events don't bubble correctly. Using the "closest" method seems like > the wrong solution here... I love the method, it is quite useful, but > in this case it causes elements to need to be sorted, and stops the > event from bubbling the way events should > > - Events and handlers are not cancelable... because of the way the > liveHandler works. > > For the benefit of those who have not looked at the code... > "liveHandler" goes through all of the stored "live" handlers/ > selectors, checks each handler for a matching event.type, then takes > the event.target and searches for the closest selector match. (This > means starting with the given element and walking up the parent tree > and testing the selector against every element until a match is found, > and storing the number of "parents" away the match is made) Then > matched elements and the current handler are stored in a temp array. > Afterwards, "liveHandler" sorts by "closest" then iterates the temp > array to finally call each handler. This all makes terrific sense, but > the biggest drawback for me, is that each handler is only called on > the first matched element. > > If I have nested divs, I would expect the "live" handler for "click" > on selector "div" to get called twice. This is (currently) not the > case. To try to work out some of these issues, I have created a plugin > to try to fix most of these issues. Here is what I tried to > accomplish: > > 1) Exposes some of the private methods so that future plugins can > modify things a little more easily. > 2) Bind the event listener to the jQuery context instead of the > document. (I think there must be a larger issue at play here) This > also only seems to work, by setting the context with a raw DOM element > like: $( context ).find( selector ) or $('selector',context). > 3) "Better" bubbling/canceling... if a handler returns false, that > handler/selector stops. if event.stopImmediatePropagation() is called, > all handlers and selectors are stopped. > 4) Creating a new method for setting up delegation without calling the > selector... using "liveConvert" > $( context ).delegate( type, selectot, handler ); > Not sure yet about data... anyway, here is some code I have been > working on and some very basic tests... > > http://dev.helgeson.info/live/http://dev.helgeson.info/live/$.live.js > > I know that there is probably some issue with "position" selectors, > but I just want to try to improve this powerful feature... --~--~---------~--~----~------------~-------~--~----~ 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 jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~----------~----~----~----~------~----~------~--~---
