RE: [clipboard events] Pasting scenarios and the shape of clipboardData.getData(‘text/html’) return value
> Also on Mac, there is no and 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 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: List of styles that apply to the markup. Classes are named copiedStyle_uniqueID Copied markup Then on paste, the DataTransferItem should contain everything on the clipboard, possibly minus OS specific things like . 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 9, 2014, at 1:58 PM, Ryosuke Niwa wrote:
> On Apr 7, 2014, at 3:37 PM, Ben Peters 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 ( and 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_" where
>> 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
>>
>>
>>
>> .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;
>> }
>>
>>
>>
>> Darth
>> Vader
>>
>>
>
> 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.
Also on Mac, there is no and 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.
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 contente
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 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 ( and 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_" where
> 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
>
>
>
> .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;
> }
>
>
>
> Darth
> Vader
>
>
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
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 ( and 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_" where
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
.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;
}
Darth
Vader
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:
.foo{border: thin solid green}.bar{border: thin solid blue}
Hello world
The text "Hello world" is selected and copied. Data types on the clipboard (as
seen through the clipboard API on paste):
text/html: Hello world
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: Hello
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:
.foo{border: thin solid green}#bar{border: thin solid blue}
Hello world
Copy "Hello world", clipboard:
text/html: Hello world
text/css: .foo{border: thin solid green}#bar{border: thin solid blue}
## Inline style attributes are kept
Document:
.foo{border: thin solid green}#bar{border: thin solid blue}
Hello world
Copy "Hello world", clipboard:
text/html: Hello world
text/css: .foo{border: thin solid green}#bar{border: thin solid blue}
How hard do you think this is to implement?
-Hallvord
