Henri Sivonen wrote:
In Gecko, it seems to dictate the internal data model even, by making
elements hold an array of children.
This has more to do with memory usage considerations than the DOM API, for what
it's worth... Using a doubly-linked list simply takes more memory per node.
But yes, the array data storage does make it fast to implement index access,
while also allowing reasonably fast next/prevSibling access a long as the
next/prevSibling getter is not called on completely random nodes. Which it's
not, usually.
One could just as easily use a doubly linked list and have fast next/prevSibling
and reasonably fast index access as long as the indices accessed are not
completely random. Which they aren't, usually.
Also, a comatose list is easier to walk since the indexes don't shift
when you remove a node during the walk.
Sure. If you plan to actually _modify_ the DOM while walking the list, then
comatose lists are much nicer in all sorts of ways. I'm not sure there's a
correct way to walk a non-comatose list while modifying the DOM unless you
prohibit mutation events from modifying the DOM.
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.
That doesn't really answer my question. Are all the same properties available
on |this| and |this.childNodes|? If so, that seems pretty odd to me (though not
actually prohibited by the DOM spec, of course). If not, I'm not sure what the
concern over namespace collisions was.
-Boris
