W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2009

[whatwg] cloneNode and HTML elements

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 15 Sep 2009 04:36:18 -0700
Message-ID: <63df84f0909150436v2f660837p832499517c3230a7@mail.gmail.com>
On Mon, Sep 14, 2009 at 9:11 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Thu, 10 Sep 2009, Olli Pettay wrote:
>> On 9/10/09 11:13 AM, Jonas Sicking wrote:
>> > On Thu, Sep 10, 2009 at 12:41 AM, Maciej Stachowiak<mjs at apple.com> ?wrote:
>> > >
>> > > My assumption based on the spec is that no element-specific internal
>> > > state should be copied, the cloning should only be DOM-wise.
>> >
>> > My assumption was always the opposite. For example for<input> elements
>> > we clone the 'value' API attribute, as well as the internal
>> > has-changed-value bit (used for form field restore when going back to
>> > a page). For<script> we copy over the has-executed bit. I'm fairly
>> > sure that the list is longer.
>>
>> I've always interpret DOM3 Core strictly; cloning an element clones the
>> object and "copies all attributes and their values" So no state copying.
>> (I noticed the input element state cloning when writing other cloning
>> related stuff.)
>
> I didn't even know about the input control state cloning. I've updated the
> spec to require that the value, checkedness, dirty value, and dirty
> checkedness flags get cloned too.

For what it's worth, we also clone:

The script-is-malformed bit (set to true if a script lacks an end tag,
used when serializing to avoid a round-trip executing a partial script
element which in theory could be a security concern)

Script line-number (used for error messages). Though this doesn't seem
particularly important given that it's only used in very weird edge
cases.

There's also something in <svg:use> elements, but I suspect that's for
some internal magic.

/ Jonas
Received on Tuesday, 15 September 2009 04:36:18 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:52 UTC