[webcomponents] Copying and Pasting a Web Component
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
Re: [webcomponents] Copying and Pasting a Web Component
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
Re: [webcomponents] Copying and Pasting a Web Component
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
Re: [webcomponents] Copying and Pasting a Web Component
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. - 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 rn...@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 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 -- morrita
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 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. 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 rn...@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 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 -- morrita -- erik
Re: [webcomponents] Copying and Pasting a Web Component
On Thu, Feb 6, 2014 at 2:54 PM, Erik Arvidsson a...@google.com wrote: All good points. One issue that we should track... On Thu, Feb 6, 2014 at 5: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. 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 rn...@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 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?
Re: [webcomponents] Copying and Pasting a Web Component
On Feb 6, 2014, at 3:56 PM, Hajime Morrita morr...@google.com wrote: On Thu, Feb 6, 2014 at 2:54 PM, Erik Arvidsson a...@google.com wrote: All good points. One issue that we should track... On Thu, Feb 6, 2014 at 5: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. 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
