[clipboard events] Pasting scenarios and the shape of clipboardData.getData(‘text/html’) return value

After working with developers inside and outside Microsoft, it seems there are several types of paste that make sense in various scenarios. For instance, 
1- if pasting into a rich document, it could be important to maintain source styling information. 
2- When pasting into a wiki from an external source, it might make more sense to maintain destination styling instead. 
3- When copying from a wiki and pasting back into that same wiki, it makes sense to maintain any special formatting on that text (inline styles) but otherwise to use the theme (style sheets). 

So this is a complex problem to solve. From what I can tell, Firefox removes the document's head (and therefore style sheets) on copy, so 2 and 3 work, but 1 doesn't. Chrome inlines a certain set of styles on copy, and removes the head, so 1 and 2 work, but 3 doesn't. IE maintains the head on copy, so all 3 can work, only by using non-standard paste APIs that require the user to allow clipboard access. We have 3 execCommand args available- paste (for 1), ms-PasteTextOnly (for 2), and ms-PasteContentOnly (which maintains the shape of html markup but not styles, somewhat like 3).

In addition, the return value of getData('text/html') also varies. In Firefox, it returns only the data between <startfragment> and <endfragment>. This again makes sense for 2 and 3 above. In Chrome, it returns everything in the clipboard item, which includes the head, body, and the <startfragment> and <endfragment>, which means cleanup is required to actually put it in the DOM. IE doesn't support this at all yet, so whenever a developer wants to change the pasted text before it shows up in the DOM, they can't*.

We need a unified story.

One possibility would be to do something similar to Firefox, but also include a text/css clipboard item, which contains styles relevant to what is copied and is available on paste via getData('text/css'). Another solution might be to build a document fragment during paste and make that available as a clipboard item that contains styles and is easier to insert into the DOM. Thoughts?

Ben Peters

* there is actually a way to do this, but it's a hack and we're trying to solve it. Currently several implementations actually move the focus to a hidden iframe, allow the paste to run, clean up the new DOM, and then move it to where the paste happened. This causes issues because the focus is moving around, and it's generally ugly.

Received on Friday, 28 March 2014 16:33:21 UTC