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

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...

> 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.

> childElements would be a filtered list, so making it live for 
> consistency would presumably be a bit more troublesome than keeping 
> childNodes live.

Yes, but no more trouble than keeping getElementsByTagName() live.  In fact, in 
Gecko it could reuse almost all of the same code.  Here is the implementation of 
getElementsByTagName:

  nsContentList *list =
    new nsContentList(this, nameAtom,  kNameSpaceID_Unknown);

Here would be the implementation of a live childElements (this is the entirety 
of the code that would have to be written, apart from the idl and function 
declaration/return boilerplate):

   nsContentList* list =
     new nsContentList(this, nsGkAtoms::_asterix,
                       kNameSpaceID_Wildcard, PR_FALSE);

All the rest is already handled by the nsContentList class, because it's needed 
anyway to handle various other NodeLists in the DOM.

Or from another point of view, childElements is just like the tBodies NodeList 
on HTMLTableElement, except it doesn't care about the namespace/localname of the 
child element.

> 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....

-Boris

Received on Tuesday, 1 April 2008 20:28:33 UTC