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`.
 The trouble is that the "copy" and "cut" query commands already exist
today, so our ability to detect the new click-to-copy/click-to-cut feature
is no better off.

Otherwise, I would expect example code to look like this
gist<https://gist.github.com/JamesMGreene/ec05eca43b1433a6a663>(currently
revision
a027ea7b0e3cac5724045e7a9758de2b863421c4<https://gist.github.com/JamesMGreene/ec05eca43b1433a6a663/a027ea7b0e3cac5724045e7a9758de2b863421c4>
).

That still seems like a lot of code.

Sincerely,
    James Greene



On Tue, May 20, 2014 at 2:48 PM, Hallvord R. M. Steen <hsteen@mozilla.com>wrote:

> >>> I wonder how fancy we can get with execCommand()'s value argument?
> >>> Could we go for something like this instead of the scripted event
> payload?
> >>>
> >>> document.execCommand('copy', false, {'text/plain':'Hello',
> >>> 'text/html':'<p><b>Hello</b></p>'});?
>
> I think
> document.execCommand('copy', false, {'dataType':'text/plain',
> 'data':'Hello'})
> will do. Authors who need more fancy options than that can listen for the
> copy event and use setData() to push other formats.
>
> I quite like that. I think I might just try to spec it and throw out the
> scripted-event-has-real-effects idea. It might even come with a better
> discovery/fallback story: if the document.execCommand() call throws, create
> a TEXTAREA (or DIV with contentEditable set), throw in the data you want to
> put on the clipboard, and select it. Then call execCommand() again without
> fancy arguments, or tell users to press ctrl-c. Or something. The point is
> that execCommand() AFAIK is expected to throw exceptions.
>
> >> Maybe, or we could propose a new API.
>
> > I've been thinking about this too. I like the idea here. Another one
> would
> > be to have a Command object, like this:
> > document.execCommand({'commandName':'copy', 'text/plain':'Hello',
> 'text/html':'<p><b>Hello</b></p>'});
>
> I like the direction of your Command proposals, but in this case I think
> adding a {'commandName':'foo'} construct where just 'foo' would do fine
> earlier complicates more than it simplifies. ;-)
>
> > Which means we could get rid of the nearly-meaningless second argument to
> > execCommand without needing to introduce a new function.
>
> Does any UA actually do something different if the second argument is not
> "false"? IE? If this is implemented precisely nowhere I'd simply attempt to
> redefine the second argument :-p but IANASL (just invented alternative to
> IANAL - S reads Spec..)
> -Hallvord
>
>