w3c / clipboard-apis Goto Github PK

This example shows that current implementation of setting clipboard event target in e.g. chromium based browsers and firefox does not follow the spec. (point 6) (handler installed on not-editable element is invoked, which is against the spec.)

Other example which follows spec. works on firefox but doesn't work on chromium based browsers.

Since there is a code 'out there' which depends on implementation rather then spec., I would suggest to change the spec. point 6 to follow current implementations:

(...)

Let target be set as follows:

If selection is empty:

• Set target to be the DOM anchor of the focusable area, or the body element if no node has focus.
  else
• Set target to be the element that contains the start of the selection in document order, or the body element if there is no selection or cursor.

(...)

or even simpler:

(...)
Set target to be the element that contains the start of the selection in document order, or the body element if there is no selection or cursor.
(...)

It would be nice to have some sort of introduction as to what the significance of these lists of API's is.

fire a clipboard event step 7.1.1. says:

Set the clipboard-event-data’s internal drag data store mode flag to read/write.

but it should be read-only instead since the script has no business writing into clipboard as the user intends to paste contents into the page from the pasteboard/clipboard.

A friendly request. In https://github.com/mdittmer/web-apis @mdittmer is working on tooling for extracting the IDL from specs linked to from Chromium's source code, for the purpose of comparing the IDLs. This will hopefully be a powerful tool for avoiding accidental differences.

In order to avoid having to use a real browser to scrape the IDL, it's useful if a <pre class=idl> block is used. This is one spec that Mark found relying on ReSpec's <dl class=pre> feature.

Note that this is already a ReSpec warning: "Defining WebIDL in dl elements is deprecated. Please use Contiguous IDL instead: https://github.com/w3c/respec/wiki/User's-Guide#webidl-support"

Since we are not doing anything in this case, we should return false from execCommand("cut"). This basically amounts to replacing the "Do nothing" part in the cut action with "Return false."

Unlike the drag and drop API definitions in the html spec, the descriptions of what the drag data store mode should be for the clipboard data are not well defined here, especially with regard to the state of the clipboard's Drag Data Store and DataTransfer objects after the cut, copy, or paste events are complete.

I would imagine that we want to have the same behavior (which prevents all interaction with the clipboard or DataTransfer after the event is fired) as is used by Drag and Drop in the spec.

The following is what I would expect the text to say, given the Drag and Drop spec. It's a little awkward in order to mirror the wording used by the drag and drop specification in the HTML spec.

There is a "Drag Data Store" associated with the clipboard. I will call this the "Clipboard Store". By default this store is in Protected mode.

When dispatching a copy or cut event:

• Set the Clipboard Store's mode to Read/Write and associate a new DataTransfer (clipboardData) with it.
• Fire the event.
• Set the Clipboard Store's mode to Protected.
• Disconnect the DataTransfer from the store (the DataTransfer can no longer affect or read from the Clipboard Store, and appears empty).

When dispatching a paste event:

• Set the Clipboard Store's mode to ReadOnly and associate a new DataTransfer (clipboardData) with it.
• Fire the event.
• Set the Clipboard Store's mode to Protected.
• Disconnect the DataTransfer from the store (the DataTransfer can no longer affect or read from the Clipboard Store, and appears empty).

The test cases are currently located in a snapshot of the spec document. Tests were previously interspersed in the spec, but this is no longer the case now that we're maintaining the spec in bikeshed.

To do:
(1) Remove spec text from the tests.html file (so that it contains only test cases).
(2) Move tests into a better location
(3) Update script that generates test cases (remove hard coded "C:\mozilla\web-platform-tests\clipboard-apis\")

A common practice when gh-pages (branch) is used is name the main file "index.html". Unless there's a good reason to keep with "clipops.html", use "index.html" instead.

I'm working to setting on a set of Permissions for the Clipboard API. Currently, we have a placeholder in the Permissions API:

Current Proposal

Because the Permissions tend to be hierarchical (with a generic top-level permission and flags for special access - see Permissions for Midi), we were settling on:

{ name: "clipboard" } <- for basic Write access
{ name: "clipboard", allowRead: true } <- for both read/write access

Since read access is more of a privacy risk than write (eg: reading passwords and PII from clipboard).

Each of these permission descriptors is set to either GRANTED, DENIED or PROMPT. So, a user agent could (for example) decide to have the following defaults:

{ name: "clipboard" } = GRANTED
{ name: "clipboard", allowRead: true } = PROMPT

And the "allowRead=true" version is known to be "stronger" than the "allowRead=false" version so the user would not be queried if a "strong" permission was already granted.

Mozilla Permissions

Mozilla's clipboard permissions are basically:

• clipboardWrite
• clipboardRead

Which makes sense as 2 independent bools, but doesn't really fit in to the basic-access/specific-access model common in Permissions.

But the Proposed Permission model described above doesn't map cleanly to Mozilla's current permissions since there is no way to grant Read access but deny Write access.

What if we had separate flags for read and write?

An alternate way of doing Permission (that we originally considered) is to instead have:

{ name: "clipboard", write: true/false, read: true/false }

This more closely matches with Mozilla has but that allows weird combinations like:

{ name: "clipboard", write: false, read: false } = GRANTED

What would this even mean? And how would it be different from having the other permissions set to DENIED?

And the "strength" relationship between the permissions in this scenario is less obvious:

write:true, read:true > write:false, read:false
write:true, read:true > write:true, read:false
write:true, read:true > write:false, read:true
but...
write:false, read:true ??? write:true, read:false
write:true, read:false ??? write:false, read:true

which means we might end up asking for permission more often (eg: asking the user for write access, then asking for read).

These oddities were why we went with the Proposal mentioned earlier.

My question is: Does the original Proposal work for Mozilla? How important is being able to grant read, but not write access?
@masayuki-nakano @smaug----

https://w3c.github.io/clipboard-apis/#clipboard-event-interfaces

There's an effort to implement the ClipboardEvent constructor in Blink:
https://code.google.com/p/chromium/issues/detail?id=496394
https://codereview.chromium.org/1178683007/

In the review I noticed some weird things, quoted here:

The spec is strange and I think it probably needs to be fixed a bit in order to be implemented. It looks like Firefox doesn't actually do what it says either, at least judging by this: new ClipboardEvent({data:'foo',dataType:'text/plain'}).clipboardData.types

the spec expresses this differently, and is pretty weird to me. As part of "fire a clipboard event" it checks if the event is trusted and uses the data and dataType arguments from the constructor without actually storing somewhere in the interim. If actually implemented like this, we'd have to add the entry to the DataTransferItemList when the event is fired, not in the constructor.

Also strange is that there's no way to actually run the "fire a clipboard event" algorithm from scripts, all of the entry points look like they're for actual copy/paste/cut actions.

How should we reach interoperability here? To me the data and dataType members don't seem very useful, and it would be more in line with other event constructors to simply take a clipboardData attribute. If DataTransfer doesn't have a constructor, maybe it should? If it shouldn't, then perhaps a ClipboardEvent constructor doesn't make sense either.

The model, as discussed in [https://www.w3.org/Bugs/Public/show_bug.cgi?id=12230](bug 12230), is:

if (target.dispatchEvent(event))
  doSomethingByDefault();

In other words, instead of saying "the default action of the beforecopy event is to ..." and (in one place) "If the event's default action is not prevented", the spec should consistently look like the cut action, where it's "fire a clipboard event named cut" followed by "if the event was not cancelled".

Also s/cancelled/canceled/ everywhere :)

It looks as though all the bugs in Bugzilla have been closed and/or migrated here, so removing the links to Bugzilla in the spec probably makes sense.

Through onbefore* events, JS can ensure copy/cut/paste UI in the browsers is enabled even if there is no selection or editable context. However, unless we spec queryCommandEnabled() to fire onbefore* events and return true if those are prevented, we risk that queryCommandEnabled() returns false even when the UI gets enabled and the actions are in fact available.

Proposal: the clipboard-apis spec can write an "enabledness check" algorithm which the editing spec can hook into.

The enabledness check will be spec'ed roughly like this:

1. Fire one onbefore event on document
2. When any event handler(s) are done, check if the default action was prevented/return value was false. If this is the case, return true for "enabledness check"
3. Otherwise, fall back to the implementation's default logic.

Criticism welcome.

DataTransfer objects can't be created by script as things stand; they can only be gotten out of an existing ClipboardEvent or DragEvent. That makes the constructor version with a DataTransfer dictionary member somewhat useless in practice... Maybe the answer is that we should in fact have a way of constructing DataTransfer objects?

Note that Firefox currently ships a version of ClipboardEventInit that takes data and dataType strings and internally constructs a DataTransfer from them....

It's a bit confusing to have this stuff separate at the end of the spec:
https://w3c.github.io/clipboard-apis/#integration-with-rich-text-editing-apis

We should probably just drop that section and add relevant steps to the actions.

Needed for whatwg/webidl#365.

Apple explains this well:

If a pasteboard item supports multiple representations, it is typically impractical or time- and resource-consuming to put the data for each representation onto the pasteboard. For example, say your application places an image on the pasteboard. For maximum compatibility, it might be useful for the image to provide a number of different representations, including PNG, JPEG, TIFF, GIF, and so on. Creating each of these representations, however, would require time and memory.

Rather than requiring an item to provide all of the representations it offers, a pasteboard only asks for the first representation in the list of representations an item offers. If a paste recipient wants a different representation, the item can generate it when it’s requested.

Has something like this been considered? For example, instead of:

var data = new DataTransfer();
data.items.add("text/plain", "foo");
data.items.add("expensive", generateExpensiveData());
navigator.clipboard.write(data);

we could have something like:

var data = new DataTransfer();
data.items.add("text/plain", "foo");
data.items.add("expensive", function () {
  // Called only when something tries to read data of the "expensive" type
  return generateExpensiveData();
});
navigator.clipboard.write(data);

Apologies if I'm not supposed to post here, I'm not sure which is the correct venue.

While the execCommand() API is appropriate for an editor or similar applications, it's rather cumbersome for the common "copy something I have in memory to the clipboard" made popular by zero clipboard.

Helpful would be an API, that would allow - after an user action - setting any content to clipboard without intercepting some event. It would also make feature detection easier, commandSupported() seems to have several issues at least in Firefox and Chrome.

I've never written any WebIDL, so this is probably horribly wrong, but I'd see the API something like this:

interface Clipboard {
  void setData(DataTransferItemList data);
};

partial interface Window {
  [Replaceable] readonly attribute Clipboard clipboard;
};

It is important to inform developers on how to manage focus with the use of the clipboard events. For example, where should focus move after a cut or paste command?

Could we work on a section that details this?

(this is part of an accessibility review for the APA WG: https://www.w3.org/WAI/APA/track/)

Under 5. Terminology:

…an input element with its type attribute set to any of text, search, tel, url, email, password or number.

Should this include all the new date types too?

As of right now, the state of the canvas is lost. Should we try to do something to handle it?

See also https://code.google.com/p/chromium/issues/detail?id=459822

Consider a page with

<div contenteditable>text</div>
<input type=checkbox>

And steps:

1. Copy something into clipboard
2. Select "text"
3. Click the checkbox to move focus. Now we have an unfocused selection on "text"
   4a. Press Ctrl+C (or Cmd+C on Mac) to trigger a copy action
   4b. Press Ctrl+X (or Cmd+X on Mac) to trigger a cut action
   4c. Press Ctrl+V (or Cmd+V on Mac) to trigger a paste action

Should these actions have effects? And what should be the clipboard event targets?

The current spec says nothing about focus, so all actions should be effective and targetting DIV following the spec.

While copying without focus may be reasonable, cut and paste are somehow different because they modify the current document. And it doesn't seem quite desirable to change an unfocused part of document in a user action. [1]

Current behaviors of different browsers (demo at https://jsfiddle.net/54scvon9/5/):

Chrome 62.0.3202.94:
copy: effective, targetted on DIV
cut & paste: ineffective, targetted on DIV [2]

Firefox 57:
All effective and targetted on the text node

Safari 11.0.1(12604.3.5.1.1):
All effective and targetted on DIV

Edge 40.15063.0.0:
All effective and targetted on DIV

[1] Discussed in crbug.com/771604
[2] This seems to be a Chrome bug: crbug.com/755459

The clipboard API in its current form is largely designed around raw text clipboard actions. I have actually found that it does not scale well for custom components.

Take, for example, the WAI-ARIA listbox example:
https://www.w3.org/TR/wai-aria-practices/examples/listbox/listbox.html

If we attempt to implement clipboard events on such a component they will not work with the current drag and drop API. The reason for this is because some browsers like Chrome add user-select: none; to elements with draggable="true" to prevent the text from being selected. Sometimes it's not the browser doing it, but the CSS author, as it can be desirable to disable text selection when dragging certain kinds of content. The ambiguity of the clipboard API doesn't clarify whether the list should still receive clipboard events.

https://bugs.chromium.org/p/chromium/issues/detail?id=754593

Perhaps the spec could be expanded to include support for such functionality?

Follow up for the #10 fix, make sure tests and examples are fixed too.

Scripts have no entry path into the "fire a clipboard event" algorithm, so this algorithm can assume that the source of the event is the user agent.

"Let trusted be true if the event is generated by the user agent, false otherwise" and "Else, if the event is generated by a script" can both be removed and much simplified.

For script-fired events, there shouldn't be anything at all to say, because it's the code dispatching the event which performs the default action. (See #14)

Some implementations support adding custom types on the clipboard, some do not. This is presumably a temporary state while implementations (and the spec) improve(s) - however, should there be a way to feature-detect whether custom types are supported?

Perhaps we should add ClipboardData.prototype.supportedTypes = ['text/plain', 'text/html', ... 'custom'] - or something like that?

https://www.w3.org/TR/clipboard-apis/#processing-model-for-event-dispatch has this text:

Set target as follows:

• If the context is editable:
  • Let target be the element that contains the start of the selection in document order, or the body element if there is no selection or cursor.
• Else, if the context is not editable
  • Let target be the focused node, or the body element if no node has focus.

It ought to define what the context is (there's a definition of what it means for a context to be editable) - presumably the focused node?

"the start of the selection" and "the focused node" ought to link to the corresponding specs. Would it make sense to define it in terms of existing APIs perhaps?

Also the definition of "the body element" in clipboard-apis links to the definition of <body> in the HTML spec, while it's probably meant to point specifically to the definition of the term "The body element of a document" in the HTML spec.

Per IRC discussion with Anne:

7:59 PM <hallvors> it's up to the UA when to fire them, but typically it would happen for example when the user opens the "Edit" menu
7:59 PM <annevk> ah right, they're unrelated to firing of the non-before events
8:00 PM <hallvors> so the UA is about to show the user a menu containing "copy"/"cut"/"paste" commands, and wants to enable or disable them
8:00 PM <hallvors> exactly. They are sort of completely unrelated to those other clipboard events..
8:00 PM <annevk> so what you actually want to define then is a set of steps for displaying "edit UI"
8:00 PM <annevk> And then you have an algorithm whenever you "display edit UI"
8:01 PM <annevk> To figure out how you display it
8:01 PM <annevk> It happens to run some script from a queued task to figure that out
8:01 PM <annevk> Do you get distinct tasks for each event? Or do they share a task?
8:01 PM <annevk> That's the kind of thing that should be obvious from that algorithm

fix paste actions to return false rather than "Do nothing"

Under 5. Terminology there is a link to a link to an API (under 4. APIs from other specs) to editing host. The partial of that link however, doesn't exist, leading readers to keep and wonder what an editing host is ;)

Right now, queryCommandEnabled("paste") in Chrome only returns true if we're in an editable area (and https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#enabled specifically mentions that cut and paste are not always enabled, though it doesn't really define when that would be).

However, executing a paste via the top-level menu or the key combination still fires a paste event at the page.

It seems like queryCommandEnabled("paste") should just match when we allow execCommand("paste") / Ctrl+V / etc?

Just like the title says, we need to add ipr functionality to the spec.

Automatic publication is failing; cf lists.w3.org/Archives/Public/public-tr-notifications/2016Dec/0085.html

labs.w3.org/spec-generator/?type=respec&url=https%3A%2F%2Fw3c.github.io%2Fclipboard-apis%2Findex.html%3FspecStatus%3DWD%3BshortName%3Dclipboard-apis returns an error, and “Not a ReSpec source document?”

See the user's guide

It's identical to W3CTRMANIFEST, which is the one being used by the automatic publication system.

From https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/pFI8AMdDChM

https://w3c.github.io/clipboard-apis/#selection-mod says "If the event listener modifies the selection or focus, the clipboard action must be completed on the modified selection". Do you know if this somewhat is meant to cover cross-origin selection/focus changes (eg, to an iframe)?

The current specified API lacks the ability to put images on the clipboard. This seems to be motivated by the concern for exploitation of security vulnerabilities in external applications (e.g. as voiced in #41 and https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0819.html).

Chrome and Firefox currently already have the ability to copy an image via the "Copy Image" context menu option, and choosing the option allows the copied image to be used in other image editing applications. In both cases, the implementation re-encodes the image before the image is exported. This technique can also be used to support putting images on the clipboard without the security concern.

To support images, at the bare minimum one image should be put on the clipboard. Other considerations are:

• Are there requirements on the images that can be copied (e.g. PNG, JPG, GIF)?
• Are there requirements on the actual copy of the image (e.g. copy as-is, convert to PNG, convert to same MIME).
• What is the number of images that can be copied (just one?)
• When does the image conversion occur (sync vs async).
• How does the API look like? (Is the image provided as a Blob/File, as a canvas/img, or maybe a typed array or string?)
• In case of animated images, which frames are copied (all? any one? the first frame?)
• Can the copied image be retrieved again from the DataTransfer instance?
• Is the answer to the previous question different for cut/copy (navigator.clipboard.write) and paste (navigator.clipboard.write)?

I submitted a patch to Firefox that offers the ability to copy images (https://bugzilla.mozilla.org/show_bug.cgi?id=1356543#c14). This is intended to be a temporary solution until we can agree on a common implementation to be shared between browsers.

// In a copy/cut event:
event.preventDefault();
event.clearData();

var blob = new Blob(['image data here'], {type: 'image MIME type here'});
event.clipboardData.mozSetDataAt('application/x-moz-nativeimage', blob, 0);
// Or, using strings (because setData is specced to only contain strings):
event.clipboardData.setData('application/x-moz-nativeimage', 'PNG image data here');

Within the cut/copy event, whatever that is assigned to the DataTransfer instance (=event.clipboardData) can be accessed as-is (via getData or mozGetDataAt). If the result is pasted, event.clipboardData in the paste event (same or other browser) will contain a File of type image/png (=the converted image, the first frame of the original image). When pasted in an image editor, the image appears as expected.

I've initially logged it on w3c/editing#168 but was directed to the Selection API / Clipboard API repos — not sure what the interdependencies are, so I'm logging it here.

I think the Copy action needs some clarification on:

3.1. Copy the selected contents, if any, to the clipboard. Implementations should create alternate text/html and text/plain clipboard formats when content in a web page is selected.

In regards to how the selection translates to HTML content. Case in point, browsers treat a Selection whose Range is set to either a Node (via range.selectNode) or a Node's contents (via range.selectNodeContents) the same way:

• Firefox will copy the Node's inner HTML to the clipboard
• Chrome and Safari will copy the Node's outer HTML to the clipboard

I believe there needs to be a way for authors to specify if the Node as a whole should be included in the clipboard, or just its content.

To do once we've agreed on (and documented) a basic design.

The before* events can be used to override the internal logic.

It would increase clarity if all event names were to be written in full here.

The beforecopy, beforecut, and beforepaste events can be used to override the internal logic.

On macOS and iOS, there could be multiple representations of multiple entires for copy & paste and drag & drop.

For example, UIPasteboard exposes items property on iOS, and each item represents multiple representations (e.g. PNG, JPEG, etc...) of a single entity (the same image).

The current DataTransferItemList representation doesn't sit well with this model because it conflates different representations of a single entry with multiple entities in the clipboard.

We need to document how we want to handle the (current) User Gesture requirement once we have proper Permissions in place.

User gestures were put in place to help reduce drive-by API abuse since we didn't have a Permission mechanism in place. Now that we have Permissions, we could remove the gesture requirement, but some UAs may want to keep the gesture requirement so that they can auto-grant some access to the clipboard without requiring a Permission prompt.

If we want to include this explicitly in the spec, here is an initial proposal:

• Write: Gesture required for clipboard write UNLESS fullAccess Permission has already been granted
  • This is because the fullAccess permission is stronger than the basic permission
  • If basic { clipboard } permission is DENIED, then write will not work (even with a gesture)
• Read: Since clipboard read is more dangerous, require { clipboard fullAccess=true } Permission
  • Note: built-in (UA or OS-level) "paste" buttons may only require a user-gesture

As mentioned in the comments here: #9 there are separate security concerns with reading and writing data for custom MIME types, so, as suggested in the thread, I'm reopening the discussion for the reading part.

It sounds like unmediated access to the clipboardData in all available formats may pose a privacy concern, so for enabling reading cusom MIME types it may be best to require some sort of consent from the user (as the previous thread suggested).

I don't feel confident enough to make a concrete proposal on how the request for permissions would work (and its implications), but I just wanted to reiterate the realm of possibility opened up by allowing reading these custom formats to be read is very exciting!

Current browser status & related issues

• Safari provides unmediated access to the clipboardData in all formats
• Chrome team is skeptical in enabling custom MIME types
• Firefox team decided on WONTFIX due to concerns raised on the Chromium thread

Currently there is no mechanism for a web app to use the clipboard to interface with a native application that uses a format not recognized by the browser.

Many (most?) native applications use custom formats that allow them to copy and paste rich featured content either within the application or across to other applications (think MS Office figures or the case I'm interested in MathCad formulas)

It's likely that many of these formats will never be mime-typed, especially for small applications and even if they were, browsers would have to be able to recognize the format in order to present it to the web app. Given the shear number of native applications and their custom formats, this problem should be passed on to the web developer who wants to develop an interface with one application, and thus only has to understand that application to write the code.

Web applications could submit their own mappings for use on that page. For example, Mathcad uses 13 different registered formats on windows. So if a web app wanted to use 2 of those formats it could call a function:

registerClipboardFormats({
   "application/vnd.mathsoft.equation+xml":[
        "XMCD Format", //Windows handle
        "MCD Format", //old Windows handle with the same format
        "XMCD_FORMAT", //Linux handle
        "com.mathsoft.xml"], // OSX handle
   "application/vnd.mathsoft.equation.meta+xml":[
        "Provenance Data", //windows handle
        "PROVENANCE_DATA", //Linux handle
        "com.mathsoft.pd"] // OSX handle
});
//returns:
//{
//   "application/vnd.mathsoft.equation+xml":true,
//   "application/vnd.mathsoft.equation.meta+xml":true
//}

Then whenever any of the OS handles are on the clipboard during a paste event those objects could be exposed via the mime-type listed. Additionally, during a copy event if one of the newly registered mime-types is set, then the browser could look to see if any of the OS handles given are registered, and those that are could be set to the data provided.

This custom registration would allow small applications to have their datatypes be recognized in a cross platform way. The only additional coding required to support more operating systems would be to add the handle name (a five minute job). Browsers could even collect and use this page specific registered data to augment the default registered datatypes if a valid registered mime-type is used if they so desired.

An additional benefit of this custom registration is that the currently undefined behavior about registering custom formats could be sidestepped by only setting formats that have already been registered by other applications. The registration function could even provide feedback as to which formats found an already registered format and which were effectively rejected. This would allow developers to notify the user that they might need to copy something with the native app and then retry. Then the web app could try to register the formats again after the native app had done the registration. This would prevent every website from registering their own formats on the native clipboard potentially maxing out the number of registration slots on windows.

For privacy reasons, UAs typically don't allow the user to cut/copy anything from within the a password field (<input type=password>). The current spec ignores this case in the cut and copy action, and at least in Gecko we're probably not going to implement that. Here is my proposal for how the spec should be changed to deal with this:

I propose the step 3 of the spec should be changed as below:

If the event was not cancelled
    If the currently focused element of the Document is a input element with type=password, return false and abort these steps.
    Copy the selected contents, if any, to the clipboard. Implementations should create alternate text/html and text/plain clipboard formats when content in a web page is selected.
else, if the event was cancelled
    Call the writing contents to the clipboard algorithm, passing on the DataTransferItemList list items, a clear-was-called flag and a types-to-clear list.

And similarly for cut, I propose to change step 3 to:

If the event was not cancelled
    If the currently focused element of the Document is a input element with type=password, return false and abort these steps.
    If there is a selection in an editable context
            Copy the selected contents, if any, to the clipboard. Implementations should create alternate text/html and text/plain clipboard formats when content in a web page is selected.
            Remove the contents of the selection from the document and collapse the selection.
            Queue tasks to fire any events that should fire due to the modification, see interaction with other events for details.
    Else, if there is no selection or the context is not editable
        Do nothing
Else, if the event was cancelled
    Call the writing contents to the clipboard algorithm, passing on the DataTransferItemList list items, a clear-was-called flag and a types-to-clear list.

These should be merged:
https://w3c.github.io/clipboard-apis/#create-a-clipboard-event-object
https://w3c.github.io/clipboard-apis/#fire-a-clipboard-event

As it is, the "Dispatch an event using the ClipboardEvent interface, with its type attribute initialized to e" step of the firing algorithm doesn't make sense if the event has already been created.

Compare with:
https://html.spec.whatwg.org/#fire-a-simple-event
https://html.spec.whatwg.org/#fire-a-click-event

I don't see any way to access the system clipboard on mouse and keyboard events.

It would be nice if the HTML5 Clipboard API could replace workarounds like ZeroClipboard.

…or of graphic content such as SVG

This is the first instance of SVG in the document, it should have a reference to the spec/definition.

Section §9.2. Writing to the clipboard currently states:

These data types must be placed on the clipboard with a corresponding native type description if added to a DataTransfer object during copy and cut events.

text/plain
text/uri-list
text/csv
text/html
image/svg+xml
application/xml, text/xml
application/json

Warning! The data types that untrusted scripts are allowed to write to the clipboard are limited as a security precaution. Untrusted scripts can attempt to exploit security vulnerabilities in local software by placing data known to trigger those vulnerabilities on the clipboard.

Is the spirit of this description that it is desirable to make this data (in a subset of known as safe data types) available outside the browser's sandbox? Is it, in fact, mandatory that browsers relay data set through copyEvent.clipboardData.setData(format, data) — where format is one of the items in the list — be available to other applications? (In particular, other web browsers)

Firefox, Chrome, and Safari are currently limiting access to the data they set through setData('application/json') and I wanted to get an opinion before I log bugs in their respective issue trackers. On the other hand they seem to allow text/html, which is subject to more obvious security and privacy concerns.

These events don't do a good job at fulfilling their use cases, have pretty much no good implementation and are confusingly named (making people think they resemble an event like beforeInput).

We can watch w3c/editing#93 to see if the editing group comes up with a generic "let the browser know that command x is enabled/disabled" feature we can use instead.