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.
