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
-~----------~----~----~----~------~----~------~--~---
