- From: Philip Jägenstedt <philipj@opera.com>
- Date: Thu, 10 Sep 2009 11:30:13 +0200
On Thu, 10 Sep 2009 11:15:06 +0200, Robert O'Callahan <robert at ocallahan.org> wrote: > On Thu, Sep 10, 2009 at 7:41 PM, Maciej Stachowiak <mjs at apple.com> wrote: > >> On Sep 9, 2009, at 10:26 PM, Robert O'Callahan wrote: >> >> If you call cloneNode on a media element, the state of the resulting >> media >>> element seems unspecified. Should it be playing the same media >>> resource at >>> the same current time as the original? >>> >>> Similar questions arise when you clone form elements; is the state >>> that's >>> not visible in the DOM cloned? >>> >>> Who should be responsible for defining this? >>> >> >> Does cloneNode require copying any state besides an element's qualified >> name, attributes and DOM children? The definition in DOM3Core doesn't >> say >> anything else should be copied. Is form control state (such as set of >> items >> selected in a <list multiple>) copied? >> >> Reference for cloneNode: >> http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-3A0ED0A4 >> >> My assumption based on the spec is that no element-specific internal >> state >> should be copied, the cloning should only be DOM-wise. >> > > It's not obvious to me that DOM 3 Core's silence means nothing else is > copied, since non-DOM state is outside its scope. > > I wonder if authors would be surprised if the non-DOM state is not > copied. I would suggest only copying state when it is needed for web compatibility or when there's a compelling use case. In the case of HTMLMediaElement the complexity of setting up a second decoding pipeline and trying to get it into the same state as the first must also be taken into account. A true clone may simply not be possible in all implementations. -- Philip J?genstedt Core Developer Opera Software
Received on Thursday, 10 September 2009 02:30:13 UTC