RE: [clipboard events] Pasting scenarios and the shape of clipboardData.getData(‘text/html’) return value
Also on Mac, there is no !--StartFragment-- and !--EndFragment-- and the serialized markup copied into the clipboard (called pasteboard on Mac) needs to contain the precisely the markup that got copied by the user. Good point. Perhaps we should make sure any OS specific items like !--StartFragment-- are not visible in developer APIs. It has a few implications but one of which is that we need to serialize some semantic elements such as a and h1 when a part of content inside such an element is selected because we don't want to simply copy the content with blue text and underline for a for example. User expects the pasted content to be a functional hyperlink if it looks like an anchor. Even elements such as b may need to be treated special because inside a contenteditable region where styleWithCSS is false, we don't want copying and pasting the content already in the contenteditable to introduce inline styles or a new style element. There are other problems with more exotic features of HTML and CSS. Another problem we recently found is that when the copied content contains position: fixed or position: sticky, we need to convert them to position: absolute and wrap the whole copied content with a position: relative box in order to prevent the pasted content to populate the paste destination. In general, it is my opinion that copy algorithm should be spec'ed at the same time as paste algorithm in the HTML Editing API, and both of them are extremely challenging task. I would say we should start by defining the shape of the html DataTransferItem rather than the way browsers should handle specific markup. So to be clearer on that, on copy, the DataTransferItem should have this shape: html head style List of styles that apply to the markup. Classes are named copiedStyle_uniqueID /style body Copied markup /body /html Then on paste, the DataTransferItem should contain everything on the clipboard, possibly minus OS specific things like !--StartFragment--. This way developers can generally count on being able to expect a full html page being available on paste, with hard styles (inline styles) in the markup, and theme styles (from the cascade) being available in the head. Implementations that don't have extra styling information in the head or inline the styles in the body don't break the model, they just don't allow the same level of control on paste.
Re: [clipboard events] Pasting scenarios and the shape of clipboardData.getData(‘text/html’) return value
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:000157
EndHTML:03
StartFragment:01
EndFragment:02
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=enspan dir=autoDarth
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
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:000157
EndHTML:03
StartFragment:01
EndFragment:02
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=enspan dir=autoDarth
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?
Re: [clipboard events] Pasting scenarios and the shape of clipboardData.getData(‘text/html’) return value
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. -Hallvord
RE: [clipboard events] Pasting scenarios and the shape of clipboardData.getData(‘text/html’) return value
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 This seems like an excellent idea! I'm not sure how hard it is to implement, but it might be doable without too much effort. Some examples to make sure we're in general agreement: ... 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.
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).
Good summary, thanks!
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
This seems like an excellent idea! I'm not sure how hard it is to implement,
but it might be doable without too much effort. Some examples to make sure
we're in general agreement:
## Copy paragraph with class name and styling:
Document:
style.foo{border: thin solid green}.bar{border: thin solid blue}/style
p class=fooHello world/p
The text Hello world is selected and copied. Data types on the clipboard (as
seen through the clipboard API on paste):
text/html: p class=fooHello world/p
text/css: .foo{border: thin solid green}
## Copy part of paragraph with class name and styling:
Same document, the word Hello is copied. Clipboard contents:
text/html: p class=fooHello/p
text/css: .foo{border: thin solid green}
## When some styles are overridden by more specific ones, all matching
selectors' declarations will still be copied
Document:
style.foo{border: thin solid green}#bar{border: thin solid blue}/style
p class=foo id=barHello world/p
Copy Hello world, clipboard:
text/html: p class=foo id=barHello world/p
text/css: .foo{border: thin solid green}#bar{border: thin solid blue}
## Inline style attributes are kept
Document:
style.foo{border: thin solid green}#bar{border: thin solid blue}/style
p class=foo id=bar style=border: 5px solid redHello world/p
Copy Hello world, clipboard:
text/html: p class=foo id=bar style=border: 5px solid redHello world/p
text/css: .foo{border: thin solid green}#bar{border: thin solid blue}
How hard do you think this is to implement?
-Hallvord
