Re: [Clipboard API] The before* events

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.
*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<http://msdn.microsoft.com/en-us/library/ie/hh781492(v=vs.85).aspx>,
> and example usage <http://ie.microsoft.com/testdrive/HTML5/msUserSelect/>).
> 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
> ****
>
>   ****
>
>  ** **
>