On Thu, Nov 1, 2012 at 4:02 AM, Travis Leithead < [email protected]> 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:* [email protected] [mailto:[email protected]] *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 <[email protected]> > 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 > > **** > > ** ** >
