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

>> However, if a scripted copy event can't take a payload and have it placed
>> on the clipboard, what's the point of making script-generated copy events
>> possible in the first place? If there's no point I'd rather disallow them.

> I don't follow. document.execCommand() is performing an *action*.
> Dispatching an event is not an action. It can be part of one, to
> notify observers, but it's not the actual thing that causes things to
> happen.

It seems somewhat confusing to generate copy events that notify listeners about something that won't happen. But I guess this is a philosophical problem that is common for all synthetic events, except the click one..

Calling document.execCommand('copy') will by itself dispatch a "copy" event. If you have some data you want to write to the clipboard, the old way to do it was more or less 

var data = 'Hello';
document.addEventListener('copy', function cp(e){
  e.preventDefault();
  e.clipboardData.setData('text/plain', data);
  document.removeEventListener('copy', cp, false);
}, false)
document.execCommand('copy', false, null);

which seems like overly cumbersome scaffolding for this use case. Hence the idea that we could just let document.dispatchEvent(new ClipboardEvent('copy', {dataType:'text/plain', data:data})) cause a real write operation to the clipboard.

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>'}); ?

- Hallvord

Received on Tuesday, 20 May 2014 10:40:48 UTC