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 <jere...@gmail.com> 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 <leeon...@gmail.com> 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 <leeon...@gmail.com> 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 <jere...@gmail.com> 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 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
-~----------~----~----~----~------~----~------~--~---
