Diego, I do not understand what you are getting at, or what the issue is...
The plugin I have provided does not have any dependency on document ordered or unordered nodes. When John's new selector engine (sizzle) is included in the core, perhaps the order of nodes may be different, but I don't see how that would effect anything I have coded. The patch I provided for the "is" method works in a similar way to what I understand of sizzle: Start with the end of the selector, then walk up the ancestor chain while working though the selector backwards, filtering out elements with each declaration. This needs to be tested, but I was surprised at the performance I have seen with this new patch. The only selectors that query the DOM at the time of binding, are those passed into the main jquery function, all other selectors passed into the delegate method are stored and only executed when the events are fired. So added and modified elements will automatically be found if they are within the event scope. Binding a "document" or "html" delegation event is completely possible before the DOM has finished rendering, the listen plugin just happens to make the "document" the default "listener" for you. Please explain what it is that I am missing, and I apologize if I am misunderstanding your points. -mike On Oct 14, 7:30 pm, Diego Perini <[EMAIL PROTECTED]> wrote: > Mike, > no, it is not about me or Matt or the others, that's how the CSS specs > are already implemented in the browsers, or will soon be (Webkit > leading the way). My selector engine is just a temporary path to > enhance browsers still not having those capabilities (all but Safari > currently !) and is optional. You can use NWEvents alone if you don't > need pseudos. > > To make it clear, I hardly believe my NWEvents code (as is) can > replace anything in jQuery. At the same time I find current jQuery > selectors are inadequate to delegation, I know John is working on it > for 1.3. This is why I wrote the NWMatcher companion. > > Every implementation has its good things, one of Ariel's plugins, for > example, DOES NOT need an "onload" event to start listening on element > "in advance". > > This small feature (that I also implement) will help drop many bugs > and inconsistencies between browser events at startup. The order is > important, elements can generate events only when they are already > rendered. So, setting up events through delegation to higher parents > (or up to document or documentElement), allow for "pre-declared" > behaviors. Like CSS does, or like XUL and IE HTC's are able to do. > > And since order is important, several W3C specs states that the > results of a selector query should return a "document ordered" static > node list. Currently only XPath, and the Selector API do that (and my > NWMatcher). > > Have you taken in consideration the fact that when the new Selectors > API will be introduced elements will be returned in a different order > than current ? > > Does your new implementation also take this in account ? > > I highly appreciate your efforts and comments, > > -- > Diego > > On 14 Ott, 21:49, "mike.helgeson" <[EMAIL PROTECTED]> wrote: > > > Ariel, Perhaps I am just polluting the plugin universe with duplicate > > features, but part of the reason I created another plugin is because I > > learn by coding. When you have an idea, do you prefer to write it out > > yourself, or tell someone else to write it for you? I guess it depends > > on the idea, but I wanted to try this one myself. > > > Matt, I did not see that thread from the other list before. The ways > > that this is different from other plugins centers around attempting to > > make this more closely match the features available with "bind"... > > > - the ability to bind "data" with a delegate handler > > - the ability to bind multiple handlers to the same selector > > - the ability to bind multiple events and multiple selectors to the > > same handler > > - the ability to stop the artificial propagation of delegates > > - the ability to selectively remove selectors, events, or everything > > > Diego, I have not had a chance to look at your code, but it seems like > > you and Matt and many more people really want to use complex > > descendant selectors. Ariels "intercept" plugin acheives this through > > the use of a document wide query through a new jquery object, and it > > sounds like Matt's theory is of a similar vein. I am very skeptical of > > the possible pitfalls that could create for many developers... > > > So I wrote a new "is" method that correctly handles complex > > hierarchical selectors. Using this new method in conjunction with a > > rewrite to "jQuery.multiFilter" allows the correct usage of complex > > selectors in any method that uses "multiFilter": > > > filter > > not > > parent > > parents > > next > > prev > > nextAll > > prevAll > > siblings > > children > > contents > > > I will include the "is" rewrite in the next plugin release, and have > > already proposed it as a patch that will hopefully get applied to the > > core. > > >http://dev.jquery.com/attachment/ticket/3137/multiFilter_patch.js > > > and related bugs... > > >http://dev.jquery.com/ticket/2266http://dev.jquery.com/ticket/2851htt... > > > On Oct 11, 1:55 pm, Diego Perini <[EMAIL PROTECTED]> wrote: > > > > 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.c... > > > > > 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 -~----------~----~----~----~------~----~------~--~---
