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

On Wed, May 2, 2012 at 6:57 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 5/2/12 2:23 AM, Aryeh Gregor wrote:
>
>> For the former, I'd suggest onbeforecontextmenu, with some way to
>> disable specific options
>>
>
> I would think that disabling cut/copy/paste would apply to main menus too,
> not just context menus.  Most people I know who use menus for this (which
> is precious few, btw, for the most part people I know seem to use keyboard
> shortcuts for cut/copy/paste) use the main menu, not the context menu...
>
> One question is whether this use case (which I agree seems worth
> addressing) requires a new event.  That is, is it better for the browser to
> fire events every time a menu is opened, or is it better for apps that want
> to maintain state like this to update some property on the editable area
> whenever their state changes and for browsers to just read those properties
> when opening a menu?
>
> The latter is, from my point of view as a browser implementor, somewhat
> simpler to deal with, since it doesn't involve having to worry about
> alert() or sync XHR or window.close() in menu-opening code.  But I can see
> that it might be more complicated to author against...


With my used-to-maintain-a-rich-text-component hat on, I would have
preferred a property to an event as an author. Most editing libraries
already have code to update the depressed state of the toolbar buttons when
the selection changes (e.g. depress the bold button if the selected text is
bold). Updating a property somewhere would naturally extend out from there.