W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2011

Re: [DOM4] parent method

From: Marat Tanalin | tanalin.com <mtanalin@yandex.ru>
Date: Tue, 27 Dec 2011 05:29:11 +0400
To: Ojan Vafai <ojan@chromium.org>
Cc: www-dom@w3.org
Message-Id: <186471324949351@web44.yandex.ru>
parent() name would be inconsistent with existing parentNode and parentNodeElement properties that walks DOM tree exactly one level up.

ancestor() name has no this issue and does exactly what it means.

To make the method name even easier to type, we could name it, for example, upTo():
element.upTo('.example');


27.12.2011, 03:19, "Ojan Vafai" <ojan@chromium.org>:
> 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 Tuesday, 27 December 2011 01:29:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:09 GMT