Re: [DOM4] parent method

I don't like the jQuery APIs as they are. :) "parent" doesn't add enough
benefit to be worth the API surface and "parents" is O(n) where the vast
majority common case is that you want the first ancestor that matches the
selector.

As far as use-cases, it's an incredibly common operation to walk up the
tree and try to find an ancestor of a given type (e.g. find the link
containing this node). Every JS library I've seen has some helper function
to simplify doing this. Making this part of the platform makes the platform
easier to work with, allows for better code-sharing (e.g. I don't have to
include jQuery just to get a few nice helper functions) and should perform
faster since all the parentNode/matchesSelector calls don't need to be
marshaled/unmarshaled between JS and C++.

I'm not opposed to calling this method "ancestor", but I prefer "parent". I
think people are more likely to look for a method named parent and it's
just easier to type. :)

On Thu, Dec 22, 2011 at 12:39 PM, Marat Tanalin | tanalin.com <
mtanalin@yandex.ru> wrote:

> Actually, jQuery has no a method that returns _first_ ancestor that
> matches required condition:
>
> -- jQuery.parent() returns first _direct_ parent;
> -- jQuery.parents() returns _all_ ancestors, not just first matching one.
>
> An appropriate name for method you're requesting would be probably
> Node.ancestor().
>
> For maximum script performance, it may make sense to have two separate
> methods (similar to having separate querySelector() and querySelectorAll()
> methods):
>
> -- ancestor() returns _first_ matching ancestor and then immediately stops
> searching up the DOM tree;
> -- ancestors() returns _all_ matching ancestors from the node to document's
> root element.
> 16.12.2011, 02:41, "Ojan Vafai" <ojan@chromium.org>:
>
> Another jquery inspired addition: we should add a "parent" method to Node
> that takes a CSS selector or a function. It walks up the tree until it
> finds a node that matches the selector/function.
> node.parent() <-- returns node.parentNode
> node.parent('div') <-- returns the first ancestor of node (walking up)
> that is a div
> node.parent(function(ancestor) { return ancestor.getAttribute("foo") ==
> "bar" }) <-- returns the first ancestor of node whose "foo" attribute has
> the value "bar"
> Open questions:
> 1. Should all selectors be allowed or just simple selectors? The former is
> easier to understand and more powerful but also easy to shoot yourself in
> the foot with (e.g. combinators can easily result in n^2 walks of the
> ancestor chain).
> 2. What should happen in the following cases? My intuition is that they
> should all return either null or node.parentNode, but I don't feel strongly.
> -node.parent("")
> -node.parent(undefined)
> -node.parent(null)
> -node.parent(5)
> I also think we should add "next" and "previous" that do the same thing as
> "parent" except they walk the sibling list, but I'm less convinced those
> are as useful.
>
>

Received on Monday, 26 December 2011 23:20:40 UTC