W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2001

RE: NodeList (was RE: NamedNodeMap)

From: Joseph Kesselman <keshlam@us.ibm.com>
Date: Wed, 11 Jul 2001 17:40:16 -0400
To: www-dom@w3.org
Message-ID: <OF0142C0B7.B4C90ED9-ON85256A86.0075F06E@pok.ibm.com>

>"When you insert it, it will be inserted into the NodeList IF the
> insertiion point is within the subtree of the node on which
> getElementsByTagName() was issued". But it also becomes
> necessary that the new Node match the tag named specified in the
> original getElementsByTagName query.

You gave the specific scenario of removing and reinserting a node. You
didn't alter it between those two operations. Ergo, in this case, it WILL
still match. (Actually, the only alteration you can make to an Element
node's name is to change its namespace prefix, and even that is possible
only if the node was generated with createElementNS.)

The basic principle is that the NodeList always responds as if the query
had just been issued. Everything beyond that is either illustration of the
implications of that statement, or implementation details.

I may already have said this, but: You might want to look at how other
implementers have solved this problem. I believe many (most?) of us have
treated the "deep" NodeList as a cache (for performance reasons), with
something similar to a "dirty" flag on the tree, or mutation events, used
to signal when it must be refreshed. That isn't necessarily the best
approach, but it seems to work.

(Note that standard DOM Level 2 mutation events won't do the job because
they could be cancelled before reaching the listener. This is one reason
"listener groups" are on the wishlist for DOM Level 3.)

______________________________________
Joe Kesselman  / IBM Research
Received on Wednesday, 11 July 2001 17:40:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:49 GMT