HTML5 clipboard support

2015-05-27 / Specs

Both Chrome and Firefox are now working on their support for the Clipboard API spec, which I’ve been editing for the last couple of years.

Clipboard support has been a neglected area for web sites. It was and still is hard-to-impossible to paste an image into an online editor, for example. Part of the reason is that while copying and pasting seems like simple functionality, under the hood it’s really complex: lots of data types you may want to or need to handle, safety precautions and considerations, extremely important and sensitive privacy concerns..

Spec’ing this we’ve tried to strike a balance between various concerns, and this is basically how it is intended to work - in a nutshell:

  • Scripts can use copy/cut events (triggered by your copy/cut commands in the browser’s trusted UI) to modify the data and data types that will end up on the clipboard
  • Scripts can use paste events (again when triggered by trusted UI) to read data from the clipboard. It will be given access to any “supported” data types and be able to process for example HTML code placed on the clipboard by Word and other editors.
  • Scripts can trigger copy/cut actions with document.execCommand() if the JS thread is considered user-initiated (here we re-use the browser’s “allowed to show a popup” logic, typically this means running from for example a click or mouseup event - check that link for full details.)
  • Scripts can not trigger paste actions, not even from user-initiated threads (though the spec leaves the door open to implementing specific permission UIs that will allow this on a per-site basis).

The only capability that is new to the web platform (although partially supported in IE for years) is getting data from the clipboard on paste events. Click-to-copy is widely used, powered by Flash. Modifying what ends up on the clipboard in copy and cut events is trivial if you change the selection or DOM from a mouseup or keypress event. In a sense, we’re taking baby steps.

Even so, there are some fully legitimate concerns that are being raised about the potential for abuse of this API. I think we’ve found a pretty good balance, and that any further annoyance can be handled in social ways by users complaining to badly behaved sites, blogging about them etc. This is already happening. In some ways, the new and simpler API will also make blocking this functionality simpler - it’s easier to write an extension to modify document.execCommand() behaviour than one double-guessing what a Flash applet is up to.

For further discussion, see the spec’s “Repository and participation” section, use the public-webapps mailing list or find me on Twitter.