- From: Mike Champion <mcc@arbortext.com>
- Date: Mon, 27 Jul 1998 19:06:14 -0400
- To: steve@crc.ricoh.com (Stephen R. Savitzky), keshlam@us.ibm.com
- Cc: www-dom@w3.org
At 05:53 PM 7/27/98 -0400, Stephen R. Savitzky wrote: >keshlam@us.ibm.com writes: > >> Unless, of course, my understanding of getElementsByTagName() is incorrect >> and it really means "get immediate children by tag name", which would make >> the whole problem cheap enough not to have to worry about... but the >> description of that method says it searches the subtree. > >I don't see how getElementsByTagName could _possibly_ return a ``live'' >NodeList unless one of the following two conditions is true: > > 1. it only returns immediate children of the given node, AND the indices > of those children in the NodeList returned are the same as their > indices in the parent node, i.e. there are some indices that contain > nulls. > >OR > > 2. Elements found by getElementsByTagName are _ripped out_ of their > original places in tree, and made into the children of a single, > possibly orphan, Node. > Neither of these are consistent with the spec. Sorry, but this *is* going to be hard to implement efficiently. I think the best implementation is to lazily evaluate the NodeList, i.e., make the NodeList be an interface that really has what we used to call a NodeIterator under the covers. That way, you only see nodes in the tree when the user asks for them. That puts the burden of capturing changes to the tree on the call to item(). Mike Champion
Received on Monday, 27 July 1998 19:06:11 UTC