W3C home > Mailing lists > Public > public-webapi@w3.org > April 2008

Re: [Element Traversal LC] access to element by index

From: Henri Sivonen <hsivonen@iki.fi>
Date: Tue, 1 Apr 2008 22:42:56 +0300
Cc: "Web APIs WG (public)" <public-webapi@w3.org>
Message-Id: <6417EDCD-53E6-40A3-9677-F4AC3CD0F724@iki.fi>
To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>

On Apr 1, 2008, at 18:41, Daniel Glazman wrote:
> Henri Sivonen wrote:
>
>> How often do people pick a single child by index (with a number  
>> know a priori) instead of iterating over children and testing each  
>> one for an interesting trait?
>
> Let me turn the problem differently : NodeList and NamedNodeMap are  
> the
> normal answers when we query a list of nodes, for instance through
> Document.getElementsByTagName() or Element.childNodes, why should this
> behave differently and why should the DOM be inconsistent here ?

I prefer iterating with nextSibling null check over iterating with  
indexed childNodes. The childNodes feature seems to have caused a lot  
of complexity in DOM implementations--and for little benefit  
considering that the normal case is forward iteration over children.

For getElementsByTagName returning a list makes sense. However, I  
think that live lists are a design bug in the DOM. They cause even  
more trouble in the getElementsByTagName case than in the childNodes  
case.

Of course, these design decisions cannot be undone at this point, but  
I don't see why they should be perpetuated in the name of consistency.  
The Selectors API, for example, returns comatose NodeLists (list dead;  
nodes pointed to live), which is much better that trying to make those  
lists live.

childElements would be a filtered list, so making it live for  
consistency would presumably be a bit more troublesome than keeping  
childNodes live. Making it comatose would be bad for perf if it is  
used a lot, though, since each call would instantiate a new comatose  
list. Moreover, the common implementation pattern is that an Element  
object itself is the NodeList returned by childNodes, so the same  
implementation pattern couldn't be used for childElements since the  
NodeList methods are already taken for the other purpose.

> I must add that XPath also allows to select the nth child of a given
> element, that Selectors can do the same through
> |#myParent > :nth-child(n)|.
>
> Apparently querying the nth element child of an element is NOT that
> uncommon:
>
> http://www.mail-archive.com/discuss@jquery.com/msg20124.html

This talks about first vs. rest. First and last are already special  
compared to, say, fifth.

> http://groups.google.com/group/jquery-en/browse_thread/thread/f49c09bb901f7aa6

This is about every nth, which could be implemented as a forward- 
iteration pass and is anyway different to just getting nth once.

> http://tinyurl.com/2wsxlc
> http://www.xml.com/pub/a/2007/01/24/whats-new-in-prototype-15.html?page=4

These aren't use cases.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Tuesday, 1 April 2008 19:43:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 1 April 2008 19:43:46 GMT