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 <hay...@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 <rn...@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