Re: [webcomponents] Copying and Pasting a Web Component

On Thu, Feb 6, 2014 at 2:54 PM, Erik Arvidsson <arv@google.com> wrote:

> 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


I think is isn't about cloning but about serialization.
Copying HTML into clipboard means it needs to be serialized into byte
stream and be read back as another tree.
Well, such hooks could be used to ensure the sate being serialized into DOM.
It'd be great if the hook supports serialization scenario as well.


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



-- 
morrita