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
