- From: Hallvord R. M. Steen <hallvord@opera.com>
- Date: Mon, 01 Nov 2010 12:42:42 +0900
- To: "Tony Chang" <tony@chromium.org>
- Cc: www-dom@w3.org, "Ojan Vafai" <ojan@chromium.org>
On Sat, 18 Sep 2010 05:59:00 +0900, Tony Chang <tony@chromium.org> wrote: > On Fri, Sep 17, 2010 at 5:47 AM, Hallvord R. M. Steen > <hallvord@opera.com>wrote: > 4) Although both IE and WebKit support before* events (beforecut, >> beforecopy, beforepaste) I've omitted them because I can't see the use >> case for these events. What distinguishes a before* event from a >> regular cut/copy/paste event? Why is it useful to have both? Are you >> aware of legacy content that requires before* events? > > I had thought preventDefault() only worked in the before events, but that > doesn't seem to be the case. Sorry, I can't seem to remember the > difference, but maybe Ojan does. I noticed this blog post: http://almaer.com/blog/supporting-the-system-clipboard-in-your-web-applications-what-a-pain Giving an actual use case for before* events: controlling the "disabled" state of cut/copy/paste entries in a menu. While this is useful and a good reason to support before(cut|copy|paste), adding these as ClipboardEvents makes the security model in the draft I'm spec'ing somewhat more shaky. I don't see any problems with allowing event.clipboardData.getData() from a paste handler - the user is presumably consciously triggering a paste, so we should give the script whatever we have. On the other hand, a before* event might fire just because the user opened the context menu or Edit menu.. That in itself certainly doesn't indicate any intention to share clipboard data with the page. In short: I'd like to support before* events, but consider making them UIEvents or just Events rather than use the ClipboardEvents interface with event.clipboardData. > Before showing the user a menu with a disabled cut entry, the > implementation should fire a beforecut event to let the script > control the disabled state of the command. > The default action of the beforecut event is to disable the > corresponding menu entry if there is no selection. IE and WebKit fire before* a lot more often that that - they also fire a beforecopy before the actual copy when you press Ctrl-C and so on. I really don't see any use case for that, especially if we drop the ClipboardEvents interface for the before* events.. This functionality is still too limited to cover all use cases. For example, one might want an application that handled beforepaste when the cursor was inside an editable element, determined by examining the event.clipboardData.types that the type(s) of content available on the clipboard were not suitable for pasting in the current location, and disabled the paste entry. The big question is of course whether we would get away with making before* events use the Event interface compatibility-wise. Opinions and experience here most welcome! -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/
Received on Monday, 1 November 2010 03:43:24 UTC