- From: Hallvord Reiar Michaelsen Steen <hallvord@opera.com>
- Date: Mon, 05 Nov 2012 15:49:27 +0100
- To: "Glenn Maynard" <glenn@zewt.org>
- Cc: "Ojan Vafai" <ojan@chromium.org>, "Travis Leithead" <travis.leithead@microsoft.com>, "WebApps WG" <public-webapps@w3.org>, "Ryosuke Niwa" <rniwa@webkit.org>, "Aryeh Gregor" <ayg@aryeh.name>, "Daniel Cheng" <dcheng@chromium.org>, "Bjoern Hoehrmann" <derhoermi@gmx.net>, sebastian@calyptus.eu, olli@pettay.fi
It's not only about the context menu (which could be "scoped" to whatever element was targeted by a right-click), it's also about the "Edit" menu or the "inline" commands in Chrome's normal application menu. Enabling the menu entries all the time breaks with existing UI conventions. > But that's the point: if you do this, then a page adding a capturing listener on window or document will cause all of these things to happen up for every element on the page, because a capturing listener might affect anything. It's the same problem "see if an event handler is registered"-type solutions always cause. Glenn, I think we both fully understand the way this works and fails - the UI quirks and why they happen. Do you have any further thoughts on the navigator.setCommandState() proposal? Would this be better somewhere else in the API (some new execCommand() argument, perhaps?)? Do you think we loose anything if we don't spec before* events? (Sorry about any mangled quoting of previous messages - using a work webmail and I don't really trust its formatting..) -- Hallvord R. M. Steen Core tester, Opera Software
Received on Monday, 5 November 2012 14:49:09 UTC