Wow, that was fast! thanks, John! --Karl
On Jan 10, 2009, at 3:30 PM, John Resig wrote: > > Ok, I just landed a fix for this. .closest() should now work as > expected (in SVN rev 6080). > http://dev.jquery.com/changeset/6080 > > --John > > > > On Sat, Jan 10, 2009 at 1:08 PM, John Resig <jere...@gmail.com> wrote: >> To explain what's happening here: .is()/.closest()/.filter() all >> behave very similarly. >> >> Let's assume that there's a page with two buttons on it. >> >> $("button:first")[0] // buttonA >> $("button:last")[0] // buttonB >> >> $("button").filter(":first")[0] // buttonA >> $("button").filter(":last")[0] // buttonB >> >> $("button").filter("button:first")[0] // buttonA >> $("button").filter("button:last")[0] // buttonB >> >> $("button:first").filter(":first")[0] // buttonA >> $("button:last").filter(":first")[0] // buttonB >> >> $("button:eq(0)").filter(":gt(0)") // Nothing found >> $("button:gt(0)").filter(":eq(0)")[0] // buttonB >> >> .is() and .closest() works identically to .filter(). >> >> So what's happening to make .live() act weird? The difference is >> between how .find("button:first") and .filter("button:first") work. >> Since with .live() we are taking a set of elements (in this case - >> only a single element - event.target) and filtering against it. This >> weirds out the positional selectors (:first, :last, etc.) since we're >> now operating relative to that single element - not the document. >> >> $(event.target)[0] // buttonA >> $(event.target).filter(":first")[0] // buttonA >> >> // New way >> $(event.target).closest("button:first")[0] // buttonA >> >> // Old way >> $("button:first").index( event.target ) // 0 >> >> I suspect that .closest() will need to be tweaked to see if it has >> one >> of these positional selectors and then act like a normal selector - >> which will end up being quite slower. >> >> If there's one thing that I've learned when doing the selector engine >> rewrite it's that these positional selectors, while a huge usability >> boost to users, weren't meant to be implemented in CSS selector >> engines as we know it. >> >> --John >> >> >> >> On Sat, Jan 10, 2009 at 12:36 PM, Karl Swedberg <k...@englishrules.com >> > wrote: >>> On Dec 30, 2008, at 3:51 PM, John Resig wrote: >>> >>> One thing i'd love to see is full selector support in $.live. since >>> >>> both $.delegate and $.listen are limited to basic selectors, leaving >>> >>> the user to filter the target inside the callback for more >>> complicated >>> >>> things like :eq, :not, :text...etc. >>> >>> .live has full selector support. >>> >>> Hi John, >>> Since .live uses .is internally (with the .closest method), it >>> only has >>> supprot for those selectors that .is supports, right? >>> So, $('li:eq(0)') would bind to all li elements, but $('li:eq(1)') >>> would >>> bind to none. Such is the quirkiness of .is and "simple selectors." >>> For example (in Firebug): >>>>>> $('button:eq(2)').is('button:eq(2)') >>> false >>>>>> $('button:eq(2)').is('button:eq(0)') >>> true >>> I'm not sure how full selector support can be achieved with .live, >>> or even >>> if it should at this point, but the documentation, at least, >>> should be >>> clear. >>> Thoughts? >>> --Karl >>> ____________ >>> Karl Swedberg >>> www.englishrules.com >>> www.learningjquery.com >>> >>> >>>>> >>> >> > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
