Re: [webcomponents] Copying and Pasting a Web Component

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