This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 12999 - Allow nodefault="" on <menu type=context>
Summary: Allow nodefault="" on <menu type=context>
Status: RESOLVED WONTFIX
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: All All
: P2 enhancement
Target Milestone: Needs Research
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords: a11y
Depends on:
Blocks:
 
Reported: 2011-06-20 09:11 UTC by Jan Varga
Modified: 2016-03-28 10:38 UTC (History)
14 users (show)

See Also:


Attachments

Description Jan Varga 2011-06-20 09:11:20 UTC
http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#context-menus

"The default action of this event is that the user agent must show a context menu built from the menu element.

The user agent may also provide access to its default context menu, if any, with the context menu shown. For example, it could merge the menu items from the two menus together, or provide the page's context menu as a submenu of the default menu."

So most of the time the default context menu will be shown along with page menu.
Anyway, in some situations (especially for web apps), there is a need to not show the default context menu.
For example http://userexperience.evantageconsulting.com/2010/08/detailed-html5-ux-designers/ (Figure 4)
Comment 1 Tab Atkins Jr. 2011-06-20 17:41:58 UTC
Hiding the default context menu is actively hostile to users.  If I'm right-clicking, I expect the default options to still be accessible (for example, I might be trying to hit "Save As", "View Source", or "Inspect Element").
Comment 2 Jan Varga 2011-06-20 17:54:12 UTC
It's mostly useful for web apps (see the link). Firefox implementation will respect this attribute only in app tabs.
Anyway, shift right click will always show the default context menu (w/o page menu)
Many web sites prevent access to default context menu anyway.
Comment 3 Tab Atkins Jr. 2011-06-20 17:56:23 UTC
(In reply to comment #2)
> It's mostly useful for web apps (see the link). Firefox implementation will
> respect this attribute only in app tabs.

Yes, it makes them slightly prettier, at the cost of usability.  Within app tabs it's not quite as big of a deal.

> Anyway, shift right click will always show the default context menu (w/o page
> menu)

That's not at all discoverable. :/

> Many web sites prevent access to default context menu anyway.

Which is actively hostile, and we should really turn off that functionality.
Comment 4 Ian 'Hixie' Hickson 2011-06-21 07:26:30 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: The whole point here is to include the UA context menu instead of replacing it.
Comment 5 Jonas Sicking (Not reading bugmail) 2011-07-14 04:58:54 UTC
Has anyone talked to web-app developers which currently hide the context menu. IIRC several google apps does this, such as google docs and google maps. Are they replacing the existing context menu because they can't add to it? Or are they replacing it because that is what they want to do?
Comment 6 Tab Atkins Jr. 2011-07-14 05:16:17 UTC
(In reply to comment #5)
> Has anyone talked to web-app developers which currently hide the context menu.
> IIRC several google apps does this, such as google docs and google maps. Are
> they replacing the existing context menu because they can't add to it? Or are
> they replacing it because that is what they want to do?

I don't care if they want to do it.  I want them to *not* do it, because I want to always have access to the normal context menu.
Comment 7 Jonas Sicking (Not reading bugmail) 2011-07-14 05:20:57 UTC
So you're going to advocate that chrome removes support for the contextmenu event? Which sole purpose is to disable the built-in context menu? As long as that's supported both silly and counter productive to not allow the ability to disable the built-in context menu items.
Comment 8 Tab Atkins Jr. 2011-07-14 05:26:50 UTC
(In reply to comment #7)
> So you're going to advocate that chrome removes support for the contextmenu
> event? Which sole purpose is to disable the built-in context menu? As long as
> that's supported both silly and counter productive to not allow the ability to
> disable the built-in context menu items.

Not necessarily.  I do need to advocate for an alternate method that is guaranteed to summon the default context menu, as the spec recommends in a MAY.  There are use-cases (largely game-related, I think) to disable the context menu popping up from a right-click.

But if you're supplying your own context menu, I don't see a reason to require even that.  A single option on the menu that summons the default context menu would suffice.
Comment 9 Michael[tm] Smith 2011-08-04 05:02:34 UTC
mass-moved component to LC1
Comment 10 Jonas Sicking (Not reading bugmail) 2011-08-22 20:16:39 UTC
Tab: I don't quite understand what UI you are advocating for.

What I'm saying is that pages currently use the contextmenu event + piles of <div>s in order to create their own context menu and remove the default one.

The <menu> element provides an opportunity to create a better situation.

By adding a @nodefault attribute, we allow websites to semantically describe that they want their context menu options to replace the default set of options.

This gives UAs a lot more freedom in creating a good user experience than the current contextmenu event + piles of <div>. With a @nodefault attribute UAs can expose UI to temporarily or permanently ignore the @nodefault.

For example UAs can have an option "allow sites to replace context menu" which chooses if @nodefault should be ignored or not. Or they can add a option at the bottom which exposes the default menu as a sub-menu. Or add an option which says "don't allow this website to replace my context menu".

UAs could even choose to expose only a set of most critical options when @nodefault is set.

Currently none of those things are possible.


Could you describe what you are hoping or expecting will happen as long as we don't have @nodefault but still do have the context menu event?
Comment 11 Jonas Sicking (Not reading bugmail) 2011-08-22 20:17:55 UTC
Meant to reopen. As long as the context menu event exists, not having @nodefault produces a strictly worse user experience.
Comment 12 Tab Atkins Jr. 2011-08-22 20:22:56 UTC
(In reply to comment #10)
> Tab: I don't quite understand what UI you are advocating for.
...
> Or they can add a option at the
> bottom which exposes the default menu as a sub-menu.

The bit I carved out above is what I expect browsers to do.  That seems an obvious and clear answer.  If you're suggesting an attribute to switch between "just add it to the existing context menu" and the above, then I'm okay with that.  I'd prefer a better name, though.
Comment 13 Ian 'Hixie' Hickson 2011-08-23 05:30:53 UTC
I think before we add this we should find out (by exposing the feature) whether authors so object to the native menu that they won't accept to coexist with it (and will instead continue to use <div>s) or if they in fact would be happy to coexist with it but today are simply incapable of doing so.

Note that the spec doesn't require that the elements be merged inline. They could be hidden behind a single context menu item. The merged items could be a subset of the full menu. The UA menu could be entirely hidden unless the user had brought up the menu while holding the shift key down. The UA could be entirely hidden if the user brought up the menu with the right mouse button but shown if the user used two fingers when pressing on the multitouch right mouse button. Only in some of these scenarios does it even make sense to expose a control to the author about what to do.

Unless and until we have a better understanding of what implementations converge on and what authors actually want, it's impossible IMHO to make an educated decision on how to support the proposal.
Comment 14 Ian 'Hixie' Hickson 2011-09-21 23:07:45 UTC
I am marking this this LATER so that we can re-examine it when we have more implementation experience.
Comment 15 Eric Sh 2011-10-24 17:46:19 UTC
I believe that authors would object to the native menu for the following reasons:
1. Web applications do not want the user feel like they are using a browser(see reason 2)
2. This is a major barrier between native applications and web applications - Authors feel that UA's limit them to always let the user know that he's using the browser and because of this they tend to use in-UA-java for native user experience without the user knowing they use a browser.
Comment 16 Tab Atkins Jr. 2011-10-24 17:53:37 UTC
(In reply to comment #15)
> I believe that authors would object to the native menu for the following
> reasons:
> 1. Web applications do not want the user feel like they are using a browser(see
> reason 2)
> 2. This is a major barrier between native applications and web applications -
> Authors feel that UA's limit them to always let the user know that he's using
> the browser and because of this they tend to use in-UA-java for native user
> experience without the user knowing they use a browser.

This seems incorrect.  Very few authors use Java on the web at all.
Comment 17 Eric Sh 2011-10-30 18:21:53 UTC
(In reply to comment #16)
> This seems incorrect.  Very few authors use Java on the web at all.

You are right that very few use java, but it was an example most actually use Flex(Flash) for native-like controls - which also adds some items to the context menu.

For example, in winows the bigger the context menu the more likely it is for it to flip(when it overflows the edges of the screen) so getting to the items added takes much more mouse movement and user annoyance.
But if authors could only show their menu items then this would not happen.
The same argument for having a lot of context menu items(either added by the author or by the browser).
Comment 18 Jan Varga 2011-11-25 11:01:34 UTC
http://hacks.mozilla.org/2011/11/html5-context-menus-in-firefox-screencast-and-code/

See the discussion about default context menu.

As I mentioned, this is needed especially for web apps.
Comment 19 Michael[tm] Smith 2013-01-24 07:16:58 UTC
This bug was cloned to create HTML WG bug 19039.
Comment 20 Ian 'Hixie' Hickson 2013-03-20 00:13:06 UTC
What's the implementation status of <menu> generally at this point? Has Firefox adjusted to match the new compromise text? Has anyone else implemented it? I'm wary of adding this before there's implementation experience from multiple vendors.
Comment 21 Ian 'Hixie' Hickson 2013-10-02 20:45:49 UTC
Punting pending a better implementation story of this part of the spec.
Comment 22 Florian Bender [fbender] 2013-10-26 14:00:18 UTC
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
Comment 23 Florian Bender [fbender] 2013-10-26 15:43:43 UTC
For backwards compatibility, it may be an idea that if `showdefault` is not specified, the UA should show the full context menu (like Firefox does atm). 

There could also be an option `none` for `showdefault` which makes the UA hide the default/"native" context menu items, like shown in the example[1] mentioned in comment 22. Thus an empty `showdefault` is not allowed / ignored. `nooverflow` (pending bikeshedding) should still be there to allow hiding the rest completely (if UA allows it). 

Thinking about it, this is probably the most sane behaviour: 
(A) If `showdefault` attribute is not present or empty on the `menu[type=popup]` element, display the default items below the added (via `<menuitem>`) items (separated by a line).
(B) For `showdefault="none"`, hide the default items which can be made visible by clicking the disclosure triangle.
(C) For all other values of `showdefault`, display the appropriate items of the group and hide all other items. These hidden items can be made visible by clicking the disclosure triangle, as long as `nooverflow` is not part of the attribute item list and the UA allows this attribute item. 


[1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-December/038472.html
Comment 24 Anne 2016-03-28 10:38:46 UTC
I'm closing this request since other vendors have still not picked up on <menu type=context> yet (http://thewebrocks.com/demos/context-menu/ does not work in anything but Firefox, although arguably this is a feature that should only work over HTTPS).

If this is still desired please file an issue on GitHub: https://github.com/whatwg/html. Thanks!