Re: [Clipboard API] The before* events

Den 1. nov. 2012 kl. 19:38 skrev Ojan Vafai <ojan@chromium.org>:

> I agree that this use case is not very important and possibly one we shouldn't bother trying to solve. Hallvord's initial point, I think is that there's really no use case for the before* events. We should kill them.

Makes it easier to ship my spec if we get a general agreement on this, so I won't exactly object to it :-) The potentially important part of the use case here is however not about *dis*abling copy/cut/paste menus. It is useful to be able to *en*able them when they would otherwise be disabled, say when there is no selection but the app/script fakes a selection of some entity or object it wants to let the user copy.

The most IMHO elegant solution is what we implemented in Opera: we simply keep relevant menu entries enabled if there are event listeners registered for the corresponding event. This sort of goes against the "registering event listeners should not have side effects" rule, but it's a UI effect the page can't detect so I guess it's ok. 

It might not be a solution we can put in the spec though..  So do we want to handle this use case or ignore it for now?


> *If* we want to meet the use case those events purported to meet (not displaying cut/copy/paste in menus), we should design a better API. It sounds like noone especially cares for that use case though. I don't hear web developers clamoring for it.
> 
> 
> On Thu, Nov 1, 2012 at 11:12 AM, Travis Leithead <travis.leithead@microsoft.com> wrote:
> You are right, that it doesn’t solve the “disabling the option in the browser chrome” case—but is that really necessary? Why would a site want to do this?
> 
>  
> 
> The only reason I can imagine is the old “we want to prevent the casual user from copying this image because it is copyrighted” scenario. In the cut/paste interaction, there are other ways to handle this such as making the control read-only, or stoping the action at the keyboard event level.
> 
>  
> 
> IE10 (and other UAs) have another solution—allow more fine-grained control over the management of selection (css property, and example usage). I can imagine a similar model for specific control over cut/copy/paste from certain parts of the page if this is a hard requirement. The CSS property means that the developer’s request can be honored by the user agent without script getting in the way of (and possibly delaying) the action.
> 
>  
> 
> From: ojan@google.com [mailto:ojan@google.com] On Behalf Of Ojan Vafai
> Sent: Thursday, November 1, 2012 4:38 PM
> To: Travis Leithead
> Cc: Hallvord R. M. Steen; WebApps WG; Ryosuke Niwa; Aryeh Gregor; Daniel Cheng; Bjoern Hoehrmann; Sebastian Markbåge
> 
> 
> Subject: Re: [Clipboard API] The before* events
>  
> 
> On Thu, Nov 1, 2012 at 4:02 AM, Travis Leithead <travis.leithead@microsoft.com> wrote:
> 
> >I'm looking at the beforecut, beforecopy and beforepaste events. I don't entirely understand their intent, it seems even more obscure than I expected..
> 
>  
> 
> I’m not sure that the use case that these events were originally designed for (which have been obscured by time), are at all relevant to site content any more. The use case of hiding the cut/copy/paste menu options, can be fulfilled by replacing the contextmenu with some custom one if desired.
> 
>  
> 
> You don't want to disable the other items in the context menu though. This also doesn't solve disabling cut/copy/paste in non-context menus, e.g. Chrome has these in the Chrome menu.
> 
>  
> 
>  
> 
> From: ojan@google.com [mailto:ojan@google.com] On Behalf Of Ojan Vafai
> Sent: Wednesday, October 31, 2012 10:21 PM
> To: Hallvord R. M. Steen
> Cc: WebApps WG; Ryosuke Niwa; Aryeh Gregor; Daniel Cheng; Bjoern Hoehrmann; Sebastian Markbåge
> Subject: Re: [Clipboard API] The before* events
> 
>  
> 
> On Tue, Oct 30, 2012 at 9:42 AM, Hallvord R. M. Steen <hallvord@opera.com> wrote:
> 
> I'm looking at the beforecut, beforecopy and beforepaste events. I don't entirely understand their intent, it seems even more obscure than I expected..
> 
> Nothing in the official MSDN documentation [1] really explains the interaction between beforecopy and copy (given that you can control the data put on the clipboard from the copy event without handling beforecopy at all, the demo labelled "this example uses the onbeforecopy event to customize copy behavior" doesn't really make sense to me either.)
> 
> I was under the impression that you could handle the before* events to control the state of copy/cut/paste UI like menu entries. However, when tweaking a local copy of the MSDN code sample [2], I don't see any difference in IE8's UI whether the event.returnValue is set to true or false in the beforecopy listener.
> 
> Another problem with using before* event to control the state of copy/cut/paste UI is that it only works for UI that is shown/hidden on demand (like menus) and not for UI that is always present (like toolbar buttons). I'm not aware of web browsers that have UI with copy/cut/paste buttons by default, but some browsers are customizable and some might have toolbar buttons for this.
> 
> I'm wondering if specifying something like
> 
> navigator.setCommandState('copy', false); // any "copy" UI is now disabled until app calls setCommandState('copy', true) or user navigates away from page
> 
> would be more usable? A site/app could call that at will depending on its internal state. Or, if we want to handle the data type stuff, we could say
> 
> navigator.setCommandState('paste', true, {types:['text/plain','text/html']});
> 
> to enable any "paste plain text" and "paste rich text" UI in the browser?
> 
>  
> 
> I don't have a strong opinion on the specifics of the API, but I agree that this is much more usable than the before* events. In the common case, web developers would have to listen  to selectionchange/focus/blur events and call these methods appropriately.
> 
>  
> 
> The downside to an approach like this is that web developers can easily screw up and leave the cut/copy/paste items permanently enabled/disabled for that tab. I don't have a suggestion that avoids this though. I suppose you could have this state automatically get reset on every focus change. Then it would be on the developer to make sure to set it correctly. That's annoying in a different way though.
> 
>  
> 
> -Hallvord
> 
> [1] http://msdn.microsoft.com/en-us/library/ms536901(VS.85).aspx
> [2] http://samples.msdn.microsoft.com/workshop/samples/author/dhtml/refs/onbeforecopyEX.htm

> 
>  
> 
>  
> 
>