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.

Received on Thursday, 10 April 2014 20:38:41 UTC