On Feb 6, 2014, at 2:20 PM, Hajime Morrita <morr...@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. I don't think there is such a consensus in the working group anymore given Jonas' argument: http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0106.html Although this copy-paste issue may well sway the argument in favor of limiting selection behavior to some extent. > 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. > - 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. I don't think this is an acceptable solution even for v1. It would mean that users can't copy a part of website they see. > 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). There is a huge difference between builtin elements and author defined custom elements. UA's builtin elements such as input elements that could be modeled as using shadow DOM are natively supported by UAs so it can be pasted into anywhere. With custom elements, this is not the case. The destination may not have their definitions. > 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. The problem is that we can't tell whether the user is initiating inter-document copy/paste or not until the user decides to paste, at which point, we may not even have the original document. - R. Niwa
