W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2014

Re: [webcomponents] Copying and Pasting a Web Component

From: Ryosuke Niwa <rniwa@apple.com>
Date: Thu, 06 Feb 2014 17:21:12 -0800
Cc: Erik Arvidsson <arv@google.com>, Hayato Ito <hayato@google.com>, "public-webapps@w3.org WG" <public-webapps@w3.org>
Message-id: <B6A01A82-A077-413F-BAC1-4ED6C20093C4@apple.com>
To: Hajime Morrita <morrita@google.com>
On Feb 6, 2014, at 3:56 PM, Hajime Morrita <morrita@google.com> wrote:
> 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.

Right.  "Hooks" for custom elements, however, are somewhat irrelevant here if we're allowing shadow DOM outside of custom elements.

I'm not really keen on the idea to let custom elements define its copy & paste behavior in that
we don't have different copy/paste behaviors among different builtin HTML elements we have.

- R. Niwa


Received on Friday, 7 February 2014 01:21:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:21 UTC