- From: <bugzilla@jessica.w3.org>
- Date: Tue, 25 Sep 2012 21:58:14 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19039
Summary: Allow nodefault="" on <menu type=context>
Product: HTML WG
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Keywords: a11y, a11ytf
Severity: normal
Priority: P2
Component: HTML5 spec
AssignedTo: dave.null@w3.org
ReportedBy: contributor@whatwg.org
QAContact: public-html-bugzilla@w3.org
CC: ian@hixie.ch, mike@w3.org,
public-html-wg-issue-tracking@w3.org,
public-html@w3.org, jonas@sicking.cc,
jackalmage@gmail.com, ayg@aryeh.name,
kennyluck@w3.org, hans.hillen@gmail.com,
eric@shedokan.com
This was was cloned from bug 12999 as part of operation LATER convergence.
Originally filed: 2011-06-20 09:11:00 +0000
Original reporter: Jan Varga <jan.varga@gmail.com>
================================================================================
#0 Jan Varga 2011-06-20 09:11:20 +0000
--------------------------------------------------------------------------------
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)
================================================================================
#1 Tab Atkins Jr. 2011-06-20 17:41:58 +0000
--------------------------------------------------------------------------------
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").
================================================================================
#2 Jan Varga 2011-06-20 17:54:12 +0000
--------------------------------------------------------------------------------
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.
================================================================================
#3 Tab Atkins Jr. 2011-06-20 17:56:23 +0000
--------------------------------------------------------------------------------
(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.
================================================================================
#4 Ian 'Hixie' Hickson 2011-06-21 07:26:30 +0000
--------------------------------------------------------------------------------
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.
================================================================================
#5 Jonas Sicking 2011-07-14 04:58:54 +0000
--------------------------------------------------------------------------------
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?
================================================================================
#6 Tab Atkins Jr. 2011-07-14 05:16:17 +0000
--------------------------------------------------------------------------------
(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.
================================================================================
#7 Jonas Sicking 2011-07-14 05:20:57 +0000
--------------------------------------------------------------------------------
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.
================================================================================
#8 Tab Atkins Jr. 2011-07-14 05:26:50 +0000
--------------------------------------------------------------------------------
(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.
================================================================================
#10 Jonas Sicking 2011-08-22 20:16:39 +0000
--------------------------------------------------------------------------------
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?
================================================================================
#11 Jonas Sicking 2011-08-22 20:17:55 +0000
--------------------------------------------------------------------------------
Meant to reopen. As long as the context menu event exists, not having
@nodefault produces a strictly worse user experience.
================================================================================
#12 Tab Atkins Jr. 2011-08-22 20:22:56 +0000
--------------------------------------------------------------------------------
(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.
================================================================================
#13 Ian 'Hixie' Hickson 2011-08-23 05:30:53 +0000
--------------------------------------------------------------------------------
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.
================================================================================
#14 Ian 'Hixie' Hickson 2011-09-21 23:07:45 +0000
--------------------------------------------------------------------------------
I am marking this this LATER so that we can re-examine it when we have more
implementation experience.
================================================================================
#15 Eric Sh 2011-10-24 17:46:19 +0000
--------------------------------------------------------------------------------
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.
================================================================================
#16 Tab Atkins Jr. 2011-10-24 17:53:37 +0000
--------------------------------------------------------------------------------
(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.
================================================================================
#17 Eric Sh 2011-10-30 18:21:53 +0000
--------------------------------------------------------------------------------
(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).
================================================================================
#18 Jan Varga 2011-11-25 11:01:34 +0000
--------------------------------------------------------------------------------
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.
================================================================================
--
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Tuesday, 25 September 2012 21:58:16 UTC