Re: Clipboard API spec should specify beforecopy, beforecut, and beforepaste events

Boris Zbarsky <bzbarsky@mit.edu> skreiv Wed, 02 May 2012 20:10:24 +0200

>> With my used-to-maintain-a-rich-text-component hat on, I would have
>> preferred a property to an event as an author.
>
> Ah, nice.  In that case, my vote is certainly for a mechanism like that!

I suggest spec'ing something like

navigator.UI.copyEnabled
navigator.UI.cutEnabled
navigator.UI.pasteEnabled

to be writeable boolean properties. Before opening a relevant menu, the  
implementation can check if a script has set these properties and enable  
or disable/hide commands accordingly.

The only use case this doesn't handle is to conditionally enable browser  
UI depending on what format(s) are available on the clipboard. A web app  
author might want 'paste' enabled if there is plain text on the clipboard,  
but not if there is RTF text or an image - or vice versa, depending on the  
app's nature and requirements. This is the only good use case for  
beforepaste events I can think of (given, of course, that we allow the  
listener to check what formats are available).

I see no use cases for beforecut and beforecopy that are not (better)  
handled with properties.

Extending oncontextmenu to allow disabling/hiding menu entries was  
suggested elsewhere in this thread. While that idea may have merit for  
other use cases, opening the "Edit" menu will not fire oncontextmenu  
AFAIK, and neither does an oncontextmenu listener typically have access to  
information regarding what formats are on the clipboard.

Hence, my current thinking is that it might be best to spec beforepaste  
*only*. If I do so, I'd prefer not doing magicish things with  
event.preventDefault() to disable/enable browser UI. I think it would be  
easier for authors to write something like

window.addEventListener('beforepaste', function(event){
 if(event.clipboardData.types.indexOf('text/plain')>-1){
  navigator.UI.pasteEnabled=true;
 }else{
  navigator.UI.pasteEnabled=false;
 }
});

Any criticism of this way forward is welcome. (For example, would authors  
expect *Enabled properties to be sync'ed by the implementation and show  
the actual state of the UI, rather than being set from the script? Would  
methods be better - navigator.UI.setCopyEnabled()?)

-- 
Hallvord R. M. Steen
Core tester, Opera Software

Received on Thursday, 3 May 2012 11:11:24 UTC