One minor thought: the data namespace is getting pretty full as people
use it more and more. It would reduce the chance of conflicts and
obscure bugs if plugins only used their own name for data (thus $
(cur).data('closest', closer) rather than 'howClose', in case someone
writes a $.fn.howClose and wants to use data).
DannyOn Jan 24, 6:23 am, Iraê <[email protected]> wrote: > John, > > Glad you liked! > > There is still room to improve it, of course. The way I did the 'howClose' > counter the $(cur)data('howClose',closer); was bothering me a little. Then I > remembered of the core internals and changed it to > $(cur).data('howClose',closer). > But it's still been used for every found element and I didn't cleanup after > the sort (didn't know if is needed). I did not want to create a new > parameter for closer because this is API stuff. But when you look to it > again may be you want to add it: > > closest: function( selector, useCounter ) { > // .... > if(useCounter) jQuery.data(cur, 'howClose', closer); > // .... > > } > > -- Irae > > On Sat, Jan 24, 2009 at 12:54 AM, John Resig <[email protected]> wrote: > > > That's totally not the solution that I would've thought of - but I > > like! I've been trying to think of ways to break it but I haven't come > > up with any yet. I'm adding this to my todo list and will definitely > > check it out for 1.3.2. > > > --John > > > On Fri, Jan 23, 2009 at 8:42 PM, Iraê <[email protected]> wrote: > > > >> I don't think it's worth it. The result will make all delegation much > > >> slower - and for a case that's quite obscure (binding two wrapped live > > >> events and expecting a different output?). > > > > I don't think this would be so obscure anymore. .live() makes it to > > > easy to bind a lot of thing even before the DOM is ready. Think of how > > > much people are out there debuggin their own apps and make .live() > > > work as .blind() works means less bothering with the browsers. > > > >> Let's say there were 100 live events bound - this would mean that 100 > > >> selectors would need to be run and for each match they would need to > > >> be sorted and compared against every other match to see which contains > > >> the other - and only then run them and stop the propagation if it > > >> exists. > > > > This indeed would be awful. I never meant that! > > > >> Again, this isn't traditional propagation occurring here - a live > > >> event is saying a very different thing from a normal bind. Unless > > >> there's a very simple solution here I don't think it's worth the > > >> effort to go in to. > > > >> --John > > > > That doesn't mean it shouldn't bee easier. So I think I've found out a > > > simple solution! =) > > > > I've filed a enhancement bug here with everything linked: > > >http://dev.jquery.com/ticket/3980 > > > > Test case:http://irae.pro.br/jquerytests/live.simulate.propagation.html > > > Working patched test case: > >http://irae.pro.br/jquerytests/live.simulate.propagation-patched.html > > > > Patch and unit tests proposal: > >http://dev.jquery.com/attachment/ticket/3980/live_ordering.diff > > > > I'm not a javascript ninja yet but I think this won't slow down > > > the .live() too much. It don't involve DOM operations and don't > > > involve selecting nothing extra either. > > > > -- Iraê --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
