Re: [webcomponents] Copying and Pasting a Web Component

On Feb 6, 2014, at 2:20 PM, Hajime Morrita <morrita@google.com> wrote:

> This seems related to discussion around selection [1].
> 
> My claim there was that the selection shouldn't cross shadow boundary, at least from the boundary crossing shouldn't be visible script.
> 
> If this invariant is kept, we can model copy-pasting in DOM land, without thinking about Shadow DOM nor composed tree because the selection sees only one level of (shadow) subtree. 

I don't think there is such a consensus in the working group anymore given Jonas' argument:
http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0106.html

Although this copy-paste issue may well sway the argument in favor of limiting selection behavior to some extent.

> This means copying/pasting does drop Shadow tree. This might look bad from pure Shadow-DOM perspective. But it isn't that bad in practice where Shadow DOM is expected to be used with Custom Elements. Though callbacks, custom element definition rebuilds shadow trees of copied elements. This is similar to what built-in elements like <input> are doing. 
> 
> This also means that:
> 
> - Each Custom Element needs to keep serializing states in non-Shadow DOM if it wants to be copy-paste ready. If you build <x-menu> and and want to make it copy-pasteable, you will have to hold <item> or something in your (non-shadow) DOM. <input> is good example. It holds state in @type and @value attributes.
> - Copying does work only between the document which give appropriate custom element definitions. This might sound bad but actually is reasonable consequence. Custom elements are useless without its definitions anyway. Defining cross-document copying of custom element is too complex to have, at least for initial version of these standards.

I don't think this is an acceptable solution even for v1.  It would mean that users can't copy a part of website they see.

> Even though there are limitations, this allows in-place copying of well-made, shadow-backed custom elements, and it aligns how built-in elements behave (in man browsers I believe).

There is a huge difference between builtin elements and author defined custom elements.  UA's builtin elements such as input elements that could be modeled as using shadow DOM are natively supported by UAs so it can be pasted into anywhere.  With custom elements, this is not the case.  The destination may not have their definitions.

> That being said, composed-tree based copying might make sense for inter-document copying and copying into non-browser environments like mailers and note-taking apps. In this case, people won't expect copied elements "live" and it will be OK to use composed-tree without scripting, that is essentially a frozen snapshot of the elements. I'm not sure if the spec should cover these though. It seems more like optimization that each UA possibly offers.

The problem is that we can't tell whether the user is initiating inter-document copy/paste or not until the user decides to paste, at which point, we may not even have the original document.

- R. Niwa