clipboard-apis
clipboard-apis copied to clipboard
w3c
Clipboard API and events
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...
Section [§9.2. Writing to the clipboard](https://w3c.github.io/clipboard-apis/#writing-to-clipboard) currently states: > These data types must be placed on the clipboard with a corresponding native type description if added to a DataTransfer object...
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...
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...
Just like the title says, we need to add ipr functionality to the spec.
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
For privacy reasons, UAs typically don't allow the user to cut/copy anything from within the a password field (``). The current spec ignores this case in the cut and copy...
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...
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...
Popular native apps on Windows read formats like `image/svg+xml` in UTF-8 form [1]. In the spec, before the payload for a format gets written to the clipboard, the content is...
