[whatwg] <menu> and friends

Fri Dec 28 20:45:14 PST 2012

(Oops, in my earlier message I cc'ed people instead of bcc'ing them, and 
this means reply-to-all replies are going to get caught in the mailing 
list software's filters. If you reply to this thread, please don't forget 
to strip the cc list down to nothing or only one or two people. If you 
forget, let me know that I should go unstick your e-mail from the mailing 
list filters.)

On Fri, 28 Dec 2012, Jonas Sicking wrote:
> >
> > 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.

Yes, I don't understand why browsers do this. It drives me crazy, as a 
user.

> 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.

Browsers don't _have_ to show their items with the contextmenu="" menu. If 
the two choices above are the only choices, then it seems to me that 
browsers should just not include their menu in the contextmenu="" menu.

> * "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.

Right, this is why I suggested that the UA should drop all non-context- 
specific items when there's a page context menu. So e.g. for Firefox, in 
the default (context menu on <body>) case, keep Inspect Element and View 
Background Image, but drop everything else.

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

In that case, when would it make sense for the browser to ever include the 
default menu items? i.e. why not make "nodefault" the default?

> 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.

Why not do this anyway, always, and forego the attribute?

> 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 proposal as it stands now is that the browsers can show only the 
page's context menu, only the user agent's context menu, or anything in 
between. I don't think it's "heavily tipped" in either direction.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'