RE: [clipboard events] click-to-copy support could be hasFeature discoverable?

> > Getting back to the question of feature discoverability, if we go with
> > using `document.execCommand` instead of synthetic event dispatching
> > with side effects, then I would expect the proper support checks to be
> > conducted with `document.queryCommandSupported` and
> `document.queryCommandEnabled`.
> 
> It would sort of be inconsistent with how queryCommandEnabled works and
> is typically used today. As far as I can tell it's typically used to enable/disable
> buttons in a editor UI, while you move through the text. Having
> queryCommandEnabled('copy') return true only during click event processing
> would for a typical editor make the "copy" button enabled only while you
> click in the document.. It would take some special-casing and logic to work
> around that.
> 
> What if we extend queryCommandEnabled somewhat and allow
> 
> document.queryCommandEnabled('copy', {'userTriggered':true}) ?
> -Hallvord

I see three different levels of support a browser could have for copy:
1) document.execCommand('copy') fires a clipboard event, and if preventDefault isn't called the browser puts the selected text on the clipboard
2) document.execCommand('copy') fires a clipboard event, but no further action happens regardless of preventDefault
3) document.execCommand('copy') does nothing and returns false.

1 is what IE does today. I believe Chrome and Firefox do 3. Are we saying that 1 or 2 is the desired behavior for click-to-copy?

To detect 3, it seems like queryCommandSupported('copy') should return false, regardless of focus of what event you're in.
Do we need to be able to detect 1 vs 2? Or are we only interested in knowing if the clipboard event will fire?

Received on Tuesday, 20 May 2014 21:25:10 UTC