Re: [webcomponents] Copying and Pasting a Web Component

All good points. One issue that we should track...

On Thu, Feb 6, 2014 at 5: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.
>
> 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.

input is actually bad because the value attribute maps to the
defaultValue property. The value property is not reflected as an
attribute.

We should add a hook to custom elements to handle cloning of internal data.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24570

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



-- 
erik

Received on Thursday, 6 February 2014 22:54:48 UTC