<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Sep 10, 2009, at 2:15 AM, Robert O'Callahan wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Thu, Sep 10, 2009 at 7:41 PM, Maciej Stachowiak <span dir="ltr"><<a href="mailto:mjs@apple.com">mjs@apple.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top: 0pt; margin-right: 0pt; margin-bottom: 0pt; margin-left: 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex; position: static; z-index: auto; "> <div class="im"><br></div> Reference for cloneNode:<br> <a href="http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-3A0ED0A4" target="_blank">http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-3A0ED0A4</a><br> <br> My assumption based on the spec is that no element-specific internal state should be copied, the cloning should only be DOM-wise.<br></blockquote><div> <br>It's not obvious to me that DOM 3 Core's silence means nothing else is copied, </div></div></blockquote><div><br></div><div>That's how I would tend to interpret its silence, unless some other spec says otherwise. But to be fair, a the DOM specs are sometimes vague on the details. For example, it doesn't explicitly say what localName, prefix or namespace a cloned element gets. Or that what text contents cloned Text nodes should have. </div><div><br></div><div><br></div><blockquote type="cite"><div class="gmail_quote"><div>since non-DOM state is outside its scope.<br></div></div></blockquote><div><br></div>DOM2 Core also defines cloneNode, and the associated DOM2 HTML does not impose any additional requirements for the HTML elements that have internal state. That would tend to support the theory that copying element-specific non-DOM state was not intended.<div><br></div><blockquote type="cite"><div class="gmail_quote"><div> <br>I wonder if authors would be surprised if the non-DOM state is not copied.<br></div></div></blockquote></div><br><div>We haven't had any bug reports about it in WebKit, and we don't clone any internal state. We do have a bug report on cloneNode for Documents, where our choice of implementation-defined behavior is to return null. We'll likely have to fix that.</div><div><br></div><div>My mental model of cloneNode is that it's equivalent to creating a brand new element with the right name and namespace, adding the appropriate attributes, and if a deep clone, copies of its children. So I would not be surprised. Others may have a different mental model.</div><div><br></div><div><br></div><div>Regards,</div><div>Maciej</div></body></html>