- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 15 Sep 2009 04:36:18 -0700
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