RE: [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). 

There is one other scenario here, which is to maintain the html shape, but not any styles.
4- When seeking to maintain lists and tables, but format them with destination styles, it makes sense to remove style elements and style rules, but keep other html ( <li> and <table> for instance ).


>>>> 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

>>> How hard do you think this is to implement?

>> Thanks for the code sample and thoughts! I'll run it by a few more 
>> developers to get deeper insight and get back to you.

>Great! Note that the code samples are just to get us started thinking about the issues we'll have to tackle if we're going to do this - if some other behaviour (say, 
>creating new class names and making up a new style sheet with generated/computed styles) is easier to implement or seems to make more sense by all means 
>suggest that other behaviour instead.

In order to support the 4 scenarios I mentioned above, we need to be able to distinguish inline css from style sheets. Your idea here about creating a new style sheet seems like a good way to go since it helps solve the selectors problem where css doesn't work the same once you remove the context by copying a section out, and it keeps the inline styles separate from the style sheets. We could include this styles in the head of the document or in a new text/css item.

On copy, we would take something like Chrome's algorithm to get relevant css for each element. For top-level elements, this would mean several rules by default to 'reset' the style, and anything other relevant styles. We would create a new class for each unique set of computed styles and give it a name that can be recognized and unique, maybe "copiedStyle_<randomid>" where <randomid> is a guid or similar. We would also remove any inline style elements like Chrome/Firefox already do. So on copy you would get something like this on the clipboard:

Version:0.9
StartHTML:0000000157
EndHTML:0000033333
StartFragment:0000011111
EndFragment:0000022222
SourceURL:http://en.wikipedia.org/wiki/Darth_vader

<html>
<head>
<style>
.copiedStyle_12345 {
 color: black; background-image: none; font-weight: normal; margin: 0px 0px 0.25em; overflow: hidden; padding: 0px; border-bottom-width: 1px; border-bottom-style: solid; border-bottom-color: rgb(170, 170, 170); font-size: 1.8em; line-height: 1.3; font-family: 'Linux Libertine', Georgia, Times, serif; font-style: normal; font-variant: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-position: initial initial; background-repeat: initial initial;
}
</style>
</head>
<body>
<!--StartFragment--><h1 id="firstHeading" class="copiedStyle_12345 firstHeading" lang="en"><span dir="auto">Darth Vader</span></h1><!--EndFragment-->
</body>
</html>

Then during copy, the text/html element would return all of this data (or the style would be in text/css instead). My devs believe having one text/html item (instead of text/css) would make it easier to get an element (by document.write for instance) that could be used with querySelector etc. Then javascript could handle scenarios 2-4 above easily by keeping or removing inline styles and elements, and 1 above could be done by calling querySelectorAll for each copiedStyle_* class and inlining those styles like Chrome does by default. Other style classes (like 'firstHeading' here) can be kept so that if you paste back into the same page, they apply again and you don't need to inline anything.

This means copy works like firefox + new classes to track styles that Chrome would currently inline. Paste works like Chrome (the text/html item returns all of the clipboard's html text). End to end, we enable the major scenarios we have identified of for copy/paste. 

Ultimately I believe the goal of this feature is just to enable functionality in an interoperable way. To make it easier to use, js frameworks could make a document object available (instead of plain text), or provide functions to accomplish 1-4 (and other paste types). Thoughts?

Received on Monday, 7 April 2014 22:38:03 UTC