- From: <bugzilla@jessica.w3.org>
- Date: Sat, 26 Oct 2013 14:00:18 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=12999
Florian Bender [fbender] <fb+w3c@quantumedia.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fb+w3c@quantumedia.de
--- Comment #22 from Florian Bender [fbender] <fb+w3c@quantumedia.de> ---
Firefox has not been updated to the latest spec yet.
IMO, I don't see why adopting the last example of [1] is not a sufficient
solution, at least for web content. The notion of a disclosure triangle/element
in (context) menus is available both on Windows and Mac, and is by far the most
usable and user-oriented solution to this problem (with a submenu showing the
"native" context menu being the second best solution).
In fact, it may be desirable for authors to indicate that the UA should in fact
show the default context menu (or parts thereof) at all times, e. g. when you
want to add a few items for a text editor, and keep the native cut-copy-paste
items visible.
So a quick idea to allow this is adding a `showdefault` attribute which
enumerates logical groups of items (e. g. `clipboard` for cut-copy-paste,
`link` for link items like "open in new tab" or "add to bookmarks", `image` for
image tasks like "open image" or "show background image", etc.) that enable
this group to be visible by default. To not complexify this further, an author
cannot declare single context menu items to show/hide but only groups of them.
Example 1:
```
<menu type="popup" showdefault="clipboard history">
<menuitem label="Rotate Clockwise" />
</menu>
```
… would result in (shortened because I'm lazy):
+-----------+
| Rotate C… |
|-----------|
| Undo |
| Redo |
|-----------|
| Cut |
| Copy |
| Paste |
|-----------|
| ▼ |
+-----------+
Whether the order of the groups can be influenced by the order of the items in
`showdefault` is something to be discussed (I assume however, that in the
interest of the user and his habits, it should not).
The list of groups (i.e. enumerable items) needs to be specified. That in turn
means that totally new items/groups need to be assessed and added to the spec
in the future, and some items may not have corresponding groups (e.g. addon
context menu items like from Firebug or Adblock Plus, or even "Inspect
Element") as they are not useful from the perspective of *web content*.
`showdefault` only makes sense for context menus and is thusly ignored for a
button popup menu.
As for (privileged/installed) webapps, there may be a reason for authors to
indicate disabling the context menu fully (i. e. no overflow item) if and when
they want their webapp to look no different from a native app, or they (are
able to) implement "native "functionality" on their own (e. g. cut-copy-paste).
So I propose to extend the above idea with a new "group" for the `showdefault`
attribute: `nooverflow` simply hides the overflow element (native context menu
should still be accessible via e. g. Shift+Click or Alt+Click) while you can
still define groups of the default context menu to be shown. This may also
allow simply reducing the items of a context menu without adding new items. See
example 2, a slight modification of example 1.
In the interest of the user, the `nooverflow` behaviour should not be the
default, i.e. the `nooverflow` item is ignored for web content while the UA can
define situations where it is honored (e.g. only for installed webapps by
default, or after the content/app requested for permission).
Example 2:
```
<menu type="popup" showdefault="nooverflow clipboard history">
<!-- no menuitem -->
</menu>
```
… would result in:
+-----------+
| Undo |
| Redo |
|-----------|
| Cut |
| Copy |
| Paste |
+-----------+
Is this something you can work with?
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#context-menus
--
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Saturday, 26 October 2013 14:00:20 UTC