Re: [announce] Intent to publish new WD of Clipboard API and Events March 11

So the biggest new addition (IMHO, at least) is the click-to-copy/cut
capability. However, as several browser vendors have already implemented
the previously published Clipboard API, I feel that we really need some way
to feature detect this new ability so we can gracefully degrade to similar
Flash-based click-to-copy functionality if the browser supports the
Clipboard API but doesn't yet support native click-to-copy.

This detection could have been a fulfilled by something like
`document.implementation.hasFeature(...)` but that method seems to have
fallen out of favor (the MDN article notes that it will always return
`true` since Firefox 19).

Similar methods like `document.queryCommandSupported` and
`document.queryCommandEnabled` are both inappropriate (as this new
capability is achieved via dispatching a `ClipboardEvent` during the
handling of a user-initiated semi-trusted event (e.g. `click`), not via a
query command) and also inconsistently supported in browsers (some throw
errors, some return false positives, etc.).

Does anyone else have any suggestions for adding adequate feature detection
to this scenario? If not, we won't [ever?] be able to gracefully degrade
the click-to-copy functionality.

Also, we aren't given any indication as to whether or not the clipboard
injection succeeds. Would it be reasonable to add an "aftercopy"/"aftercut"
event in which we could validate the data that made it into the clipboard
(if ANY) matches our expectations?

    James Greene
    Sent from my [smart?]phone
On Mar 4, 2014 8:59 AM, "Arthur Barstow" <> wrote:

> Hallvord is working toward publishing a new WD of Clipboard API and Events
> on (or around) March 11, based on [ED].
> If you have any comments about this proposal, please reply to this thread
> by March 7 at the latest.
> -Thanks, AB
> [ED] <
> html?specStatus=WD;publishDate=2014-03-11;previousPublishDate=2013-04-11>

Received on Tuesday, 4 March 2014 16:58:51 UTC