slight addition/correction to above:
$(this).ancests(":eq(0)"); // parent
$(this).ancests("li:eq(0)"); // filtered parent
also if .and() is used to retain self, as i put above, ancest() isnt
necessarily accurate wording since if it can select itself then it
really isnt its own ancestor (ewww?). but then again, parents(:eq(1)),
isnt really a parent either. heh
On Jan 14, 11:28 am, Leeoniya <[email protected]> wrote:
> ah, i didnt know parents() worked that way, i thought it was just a
> (.parentNode & .is()) loop rather than a full DOM parentNode loop
> followed by a filtering the resultset.
>
> I should say i feel .parents() should have probably been ancests(), i
> always found the parent/parents method pair kinda misleading. really
> all you need to replace parents() and parent() and .closest() is
> something like
>
> $(this).ancests("li:eq(0)"); //parent
> $(this).ancests("li"); //parents
> $(this).and().ancests("li:eq(0)"); //closest
>
> then internally switch the algo used to do the traversal. if an
> positional selector is passed into ancest such as :first or :eq(),
> operate same as .closest does now, analyzing one at a time up the
> tree, otherwise work like .parents() and do full tree .parentNode loop
> and filter down (the complexity of the actual algo switch can be
> tweaked afterwards). leaving the current methods as aliases for
> backwards compatibility of course.
>
> perhaps this is a workable idea for the future. it would definitely
> make things more uniform, of course without peeking at the code these
> are speculations at best : )
> Leon
>
> On Jan 14, 11:03 am, John Resig <[email protected]> wrote:
>
> > The major reason is that while the functionality is equivalent -
> > closest is significantly faster (since it's able to process each
> > element one element at a time rather than finding all elements then
> > filtering).
>
> > This was discussed in the Delegation Filtering Performance part of the
> > release:http://docs.jquery.com/Release:jQuery_1.3#Live_Events
>
> > --John
>
> > On Wed, Jan 14, 2009 at 11:57 AM, Leeoniya <[email protected]> wrote:
>
> > > John,
> > > closest() which i feel should have been first-ancest-or-self() is
> > > nearly functionally identical to parents("li:eq(0)").andSelf
> > > ()....except andSelf would need to prepend to the collection rather
> > > than append, since position matters.
>
> > > was there a reason for creating a near-identical method? seems like it
> > > would have been easier to just make a way to prepend to a collection,
> > > which would yield the full functionality of closest()...maybe
> > > something like $("p").add("span").parents("li:eq(0)");...this seems
> > > much more logical and much more flexible to me, despite its longer
> > > notation.
>
> > > On Jan 14, 10:32 am, Leeoniya <[email protected]> wrote:
> > >> well, if the function will require a predefined scope, then it's kind
> > >> of pointless to create a new method for something that can easily be
> > >> done by pre-speccing the context in a single selector ahead of time
> > >> eg: .parents(":eq(3)"), you would still need to use index(), but
> > >> essentially all you'd be doing is wrapping the above 3 lines into a
> > >> new method, i dont think thats a good way to go.
>
> > >> i do agree that its expensive without knowing the scope, but otherwise
> > >> it loses much of its usefulness.
>
> > >> i'm writing a plugin that needs to override and replicate the default
> > >> tabindex behavior (which in firefox annoyingly autoselects the text
> > >> inside the input field, which is not desirable in my situation. i
> > >> realize the situation might be different because the browser probably
> > >> pre-indexes all tabbable elements and doesnt need DOM traversal on
> > >> each tab press. the nextest feature would definitely be intensive.
>
> > >> ...have some more thinking to do on a reasonable compromise. caffeine
> > >> shall aid this process.
> > >> Leon
>
> > >> On Jan 14, 10:15 am, John Resig <[email protected]> wrote:
>
> > >> > > i've been using chains like this all over my webapp:
>
> > >> > > $(this).parents("li:eq(0)")
>
> > >> > > it seems that closest is a direct replacement for this and a
> > >> > > functional equiv of
>
> > >> > > $(this).closest("li").
>
> > >> > It's almost equivalent to that. There's the possibility that if 'this'
> > >> > is an li element that it will be returned. closest always starts with
> > >> > the current element then works its way up.
>
> > >> > > also, is there anything like
>
> > >> > > nextest() that works outside the bounds of the parent container? for
> > >> > > example:
>
> > >> > > <span>
> > >> > > <b id="foo">bar</b>
> > >> > > </span>
> > >> > > <span>
> > >> > > <b>Hello!</b>
> > >> > > </span>
>
> > >> > > $("#foo").nextest("b") would return the second <b> node in the tree
> > >> > > following the current element, but not a sibling. right now i'm
> > >> > > needing to create funky ways to do this, unless i'm missing
> > >> > > something.
>
> > >> > > right now i'm forced to do:
>
> > >> > > var $e = $("#foo");
> > >> > > var i = $("b").index($e);
> > >> > > var finally = $("b:eq(" + (i+1) + ")");
>
> > >> > > ..also consider than in real life $e is not retrieved by id but is
> > >> > > "this" inside a function and often inside of a .each loop.
>
> > >> > Maybe. I'm wary of a function like this since it would have to be very
> > >> > "smart" about where to look - and that can get expensive.
>
> > >> > A better method might be something like: .nextCousin(), .prevCousin(),
> > >> > .nextUncle(), .prevUncle() :)
>
> > >> > --John
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
