- From: Mike Champion <mcc@arbortext.com>
- Date: Tue, 28 Jul 1998 17:05:27 -0400
- To: steve@crc.ricoh.com (Stephen R. Savitzky), www-dom@w3.org
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