- From: Aryeh Gregor <ayg@aryeh.name>
- Date: Thu, 3 May 2012 09:32:00 +0300
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: public-webapps@w3.org
On Wed, May 2, 2012 at 4:57 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > 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... Ah, good point. > 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... I'd have said that it would be easier as an author to not have to track state. But I'll certainly defer to Ojan's expertise here.
Received on Thursday, 3 May 2012 06:32:54 UTC