On Apr 7, 2014, at 3:37 PM, Ben Peters <ben.pet...@microsoft.com> wrote:
>>>>> 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 ). Right, that's an important use case to address. >>>>> 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> Somewhat tricky issue here is that when this content is pasted into some page, that page may also have other CSS rules defined. Depending on selectors they use, they might have a higher precedence than the single class name we use in the copied content. We could add !important to each property but that could cause an issue if the pasted content is later edited, say, inside a contenteditable region. > 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? I think providing a mechanism to serialize DOM preserving the style is a useful feature to have in general. - R. Niwa
