[whatwg] <menu> and friends

[Jonas Sicking]

On Fri, Dec 28, 2012 at 5:23 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Sat, 22 Oct 2011, Jonas Sicking wrote:
>>
>> I filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=12999 on this a
>> while ago. So far no changes to the spec though.
>
> I'm not sure I really agree with the premise of the bug. It points to this
> image as a reason for not showing UA context menu items:
>
>    http://userexperience.evantageconsulting.com/wp-content/uploads/2010/08/html5-context-menu.png
>
> ...but that to me is a perfect example of why this is a misfeature.
> Where's "Inspect Element", for example?
>
> I think it would make sense for browsers to skip the less important menu
> items (those that are accessible via the menus, for instance) when showing
> a context menu that the author is providing. (But then, I think it would
> make sense to not show those ever.) But for things that are only sanely
> accessible via the context menu, I don't see why we'd drop them.

I would mostly agree with your reasoning here if it weren't for the
fact that all UAs by default already allow webpages to hide the
context menu of any part of the page.

As long as that remains the case we are giving authors two options:
A) Use "pile of <div>s" to render context menu and get full control
over what is rendered in the context menu.
B) Use <menu> to create a more accessible menu, but accept that they
will always be listed together with a list of UA items.

There's also the following facts to take into account:
* As far as I know, no UA has expressed willingness to drop the
ability to hide UA context menus. I.e. there is no indication that the
above two options will change.
* Authors tend to prioritize control of UX over platform integration
and accessibility.
* "more options" isn't always equivalent to "better UX". I.e. even a
website that has the intent and knowledge to design the, for the user,
perfect UX would hide many or all of the built-in menu items in many
cases.

All of this makes me think that in very many cases authors will choose
option A above.

We need to remember that convincing UAs to implement this feature is
just the first step here. Convincing authors to use it is the second.

Additionally, the nodefault attribute proposed in [1] can be treated
by the UA as a hint without risking pages breaking. For example it
could choose to hide only non-critical menu items. Or hide none of
them but move them into a sub-menu. While mean that authors still
wouldn't have 100% control over the UX, they would have dramatically
more control than as the proposal stands now, heavily tipping the
scale towards option B.

The "pile of <div>s" mechanism that websites use today doesn't permit
any of the control that [1] permits since ignoring the contextmenu
attribute in many cases effectively breaks websites. And it certainly
doesn't permit combining website menuitems with UA menuitems.

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=12999

/ Jonas