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: Wed, 2 Apr 2008 00:16:29 +0300
Cc: "Web APIs WG (public)" <public-webapi@w3.org>
Message-Id: <0B74F028-3F2E-43B1-8D03-FE9C53F9CE42@iki.fi>
To: Boris Zbarsky <bzbarsky@mit.edu>

On Apr 1, 2008, at 23:27, Boris Zbarsky wrote:
> Henri Sivonen wrote:
>> The childNodes feature seems to have caused a lot of complexity in  
>> DOM implementations
> Really?  What sort?  I'm only familiar with the Gecko implementation  
> here, but I don't see it causing extra complexity there...

In Gecko, it seems to dictate the internal data model even, by making  
elements hold an array of children. In implementations that use doubly- 
linked sibling lists, the NodeList needs to be kept in sync somehow  
when the underlying linked list is modified.

>> 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.
> There are tradeoffs both ways.  Which one is better really depends  
> on the expected use cases.  If you expect to walk the whole list,  
> comatose makes some sense.

Also, a comatose list is easier to walk since the indexes don't shift  
when you remove a node during the walk.

>> Moreover, the common implementation pattern is that an Element  
>> object itself is the NodeList returned by childNodes
> Really?  You mean document.body.item(5) does the same thing as  
> document.body.childNodes.item(5)?  And that this is "common"?  I  
> must have missed it....

I mean that the getter implementation for childNodes is roughly  
"return this;".

This pattern is used in Crimson, Xerces and GNU JAXP DOM  
implementations. Since Gecko keeps an array of children, I thought it  
was used in Gecko, too, but I didn't check. I should have. Apparently  
the pattern isn't as common in C++.

Henri Sivonen
Received on Tuesday, 1 April 2008 21:17:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:10:00 UTC