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 <[email protected]> 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 [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
-~----------~----~----~----~------~----~------~--~---
