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

Re: Should Document.cloneNode() work in Level 1?

From: Stephen R. Savitzky <steve@crc.ricoh.com>
Date: 09 Sep 1998 13:07:50 -0700
To: John Cowan <cowan@locke.ccil.org>
Cc: DOM List <www-dom@w3.org>
Message-ID: <qchfyh82y1.fsf@gelion.crc.ricoh.com>
John Cowan <cowan@locke.ccil.org> writes:

> Stephen R. Savitzky wrote:
> > It is reasonable to expect that cloneNode will copy _everything_ that it is
> > meaningful to copy
> I have no such expectations.

My point is that the specification does not preclude such an interpretation.

> # Returns a duplicate of the node, i.e., serves as a generic copy
> # constructor for Nodes. The duplicate node has
> # no parent (parentNode returns null.).

This makes no mention one way or another of any private information, nor
should it.  I think that in many implementations of the DOM there _will_ be
implementation-specific information in a Node, and in that case cloneNode
_should_ be expected to copy it.

> I believe cloneNode to be a convenience method.  Everything it does
> can be done with:
> 	switch (this.nodeType) {
> 	case ELEMENT_NODE: new = this.ownerDocument.createElement(...)
> 		new.setAttributes(this.getAttributes)
> 		break
> 	case TEXT_NODE: new = this.ownerDocument.createText(...)
> 	etc. etc.

In some implementations this will not be the case.  In fact, it's not even
the case for the public interfaces, since there are attributes of, say,
HTMLDocument and HTMLElement that are not accessible from the result of
createElement without type-casting.  

 Stephen R. Savitzky   Chief Software Scientist, Ricoh Silicon Valley, Inc., 
<steve@rsv.ricoh.com>                            California Research Center
 voice: 650.496.5710   fax: 650.854.8740    URL: http://rsv.ricoh.com/~steve/
  home: <steve@starport.com> URL: http://www.starport.com/people/steve/
Received on Wednesday, 9 September 1998 16:03:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:04 UTC