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

>>> 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

Received on Tuesday, 20 May 2014 19:48:35 UTC