Re: parentNode

At 07:45 PM 7/27/98 -0400, Stephen R. Savitzky wrote:
>The DOM specification states:
>    parentNode 
>           The parent of the given Node instance. All nodes, except
>           Documents and DocumentFragments, have a parent. If a node has
>           just been created and not yet added to the tree, it has an
>           implicit parent which is a DocumentFragment.

I don't get the sense that the WG wants to reconsider this; but I will
propose some wording that I plan to add to the spec to explain what we have
in mind.  If people outside of the IG/WG really howl I suppose we could
reconsider, but please give this a fair hearing:

[I'll send a separate message proposing wording explaining why Atrribute nodes
should not have parents; this *is* under discussion by the WG]

parentNode 
The parent of the given Node instance. All nodes, except Attributes,
Documents and DocumentFragments, have a parent. If a node has
just been created and not yet added to the tree, it has an
implicit parent which is a DocumentFragment.  

All nodes are created in association with an active Document object because
many existing implementations do not allow free-standing objects, or
objects that span multiple documents.  DocumentFragment objects have a
masterDoc attribute that reflects the document that it and its contents are
associated with.  By having the implementation implicitly create a
DocumentFragment as the parent for every Node that is created, there is a
way for the DOM user to track the Document that is associated with every
node, even if it does not currently exist in the document tree. (Note that
the implementation may "lazily" create the DOM DocumentFragment on demand,
i.e., when the parentNode of a Node is accessed).

Furthermore, a DocumentFragment object will often be needed as a
"scratchpad" upon which to build up a subtree of new objects before they
are inserted into an actual document tree, or when moving a subtree from
one part of a document to another, especially since various operations such
as insertBefore and appendNode may take DocumentFragment objects as their
argument and will move the entire contents to the new location.  

[In short, by insisting that DOM implementers always have a
DocumentFragment associated with a Node or subtree that has not yet been
put in a tree or has been cut out of a tree, we make it easier for users to
track and manipulate those nodes.]

Mike Champion

Received on Tuesday, 28 July 1998 17:05:49 UTC