Re: [webcomponents] Copying and Pasting a Web Component

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.

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.

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).

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.

[1] http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0097.html


On Thu, Feb 6, 2014 at 11:34 AM, Ryosuke Niwa <rniwa@apple.com> wrote:

> Okay, one significant implication of serializing the composed tree is that
> cutting & pasting a component would result in "breaking" all components
> within cutting and pasting them in place (i.e. cmd/ctl-x + v at the same
> location).
>
> This would mean that web components are pretty much unusable inside
> content editable regions unless the author add code to fix up and revive
> serialized components.
>
> But I can't think of a way to work around this issue given we can't tell,
> at the time of copy/cut, whether the content will be pasted in a document
> with a give custom element.
>
> The most devastating requirement here is that the pasted content can't run
> any script for security reasons.
>
> - R. Niwa
>
> On Feb 6, 2014, at 5:03 AM, Hayato Ito <hayato@google.com> wrote:
>
> I remember that there was a session to discuss this topic last year's
> blinkon conference.
>
> -
> https://docs.google.com/a/chromium.org/document/d/1SDBS1BUJHdXQCvcDoXT2-8o6ATYMjEe9PI9U2VmoSlc/edit?pli=1#heading=h.ywom0phsxcmo
>   Session: 'Deep Dive on editing/selection'
>
> However, I couldn't find non-normative notes attached there. I guess no
> one has clear answer for this topic yet unless there is a progress.
>
>
>
> On Thu, Feb 6, 2014 at 6:57 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>
>> Hi,
>>
>> What is expected to happen if a custom element or an element with shadow
>> DOM is copied and pasted from one contenteditable area to another?
>>
>> Are we expected to serialize the composed tree and paste that?
>>
>> We can't keep the shadow DOM structure as there is no serialized form for
>> it, and no script could run when it's pasted.
>>
>> I understand that there is no normative documentation on how copy and
>> paste work to begin with but I'd like to see at least a non-normative note
>> as to what UAs are expected to do since this would surely have a huge
>> compatibility and usability implications down the road.
>>
>> Any thoughts?
>>
>> - R. Niwa
>>
>>
>
>
> --
> Hayato
>
>


-- 
morrita