[whatwg] <menu> and friends

[Ian Hickson]

On Mon, 31 Dec 2012, Jonas Sicking wrote:
> On Fri, Dec 28, 2012 at 11:07 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Fri, 28 Dec 2012, Jonas Sicking wrote:
> >>
> >> I don't think it's a good solution to leave it undefined if 
> >> all/none/some of the UA menuitems are displayed by default. While it 
> >> on an API level won't break anything, authors consider as "breaking" 
> >> a lot more things than APIs not behaving as expected.
> >
> > I'm happy to give guidance that happens to match what the browser 
> > vendors want to do anyway, but I don't think it makes sense to make a 
> > page- undetectable UI detail like this a conformance requirement.
> 
> I agree that defining exact UI is a bad idea. However I think we should 
> define the semantic meaning of the context menu. If the semantics are 
> that the context menu provided by the page is intended to be additional 
> context actions, or alternative context actions.

I've tried to add more text to the spec to encourage UAs to not show the 
UA menu items as prominently. Is that sufficient? We're constrained in 
what we can do, given that this is UI stuff.


> >> So are you proposing that the default should be that no UA menu 
> >> options are displayed. I.e. the default being as if nodefault was 
> >> set?
> >
> > As a user, I would hate that. But if you as a browser vendor are 
> > telling me as a spec writer that this is what would be needed to 
> > convince authors to not use <div>s for context menus, then yes.
> 
> What I was saying as a browser vendor is that I don't think that authors 
> are going to use this feature unless it provide the ability to replace 
> the existing context menu. Or at least almost entirely replace it.

Sure. Honestly, though, I think the bigger blocker right now is that 
there's only one implementation (and it doesn't match the spec).


> You are the one that is requesting that we only have a single mode.

Well, I think in general it's pretty uncontroversial that, all other 
things being equal, APIs are better if they have less surface area. So 
sure, I'd rather we not have multiple modes if we don't need them.


> If we are to fulfill both these requirements then yes, we end up with 
> something that both you and I would hate in many cases.
> 
> The alternative that I have proposed, but that you so far have rejected, 
> is the ability for the author to select mode, i.e. select if he/she 
> wants to replace or add to the existing menu.

If the options are:

 - authors never use the feature
 - users lose their control over their browser
 - the feature has a complicated API

...then we're stuck in a bad place, certainly. But I don't think those are 
the only options; what about these, for instance:

 - authors use the feature anyway, and like that it gives users power
 - browsers default to showing mainly the author's menuitems, but offer
   a discoverable way for users to find more options if they need them

Ok, the first of these two might be too optimistic, but the second should 
be workable, no? That's what the spec now suggests. I've added an example 
that shows how this could work:

Before (only the author's commands):
http://www.whatwg.org/specs/web-apps/current-work/images/contextmenu-collapsed.png

After (the user having clicked a disclosure widget):
http://www.whatwg.org/specs/web-apps/current-work/images/contextmenu-expanded.png


> > As a user, what I would like to be the behaviour, without the ability 
> > for the author to override it, is for the context menu to have the 
> > author's context menu items plus the context-sensitive items that 
> > cannot be accessed via the regular menus (e.g. Inspect Element, View 
> > Image, Copy Link Location, that kind of thing).
> 
> The ability to override the authors request of replacing the context 
> menu seems like a quality of implementation issue. For example I would 
> imagine that Firefox would hook up the already existing "allow authors 
> to replace context menu" UI option to control whether the nodefault 
> attribute was honored.
> 
> Likewise chrome could supply an extension to do the same thing.

Personally, I don't want to prevent authors from providing me with 
features. I just want to prevent them from removing features. What I want 
is the union of the site's features and the browser's features. Firefox's 
"allow authors to replace context menu" UI option is IMHO insufficient.


> >> I guess I could live with that as long as there was a way for the 
> >> page to opt in to displaying items. It would allow adding more 
> >> finegrained control over which categories of menu items are turned 
> >> backed on which could be neat.
> >
> > I'm very skeptical about adding any kind of control here before we 
> > have broader implementation experience. Once we do, then it will be 
> > revisited anyway, since we have this bug on file:
> 
> I doubt that I can change your mind on this. But I'll note that that 
> means that that likely means that we'll have to make the default 
> behavior the behavior that you like less.

I think it's possible to have a default behaviour that both does what 
authors want, and gives users full access to the browser commands.


> > What items are there that it sometimes makes sense to expose but 
> > othertimes does not make sense to expose?
> 
> I'm not sure I understand the question.

If we allow authors to replace the menu entirely, then that means we think 
that there are times where there are context menu items that shouldn't be 
shown, which would have been shown, if the author hadn't replaced the 
menu. I'm asking, what are those menu items? What commands are there that 
we sometimes think are important enough to expose (that's why they're in 
the context menu), but other times think they are unimportant enough that 
we can just prevent access to them (that's why we let the author replace 
them)? It seems weird to me that we'd have any such commands.


On Fri, 4 Jan 2013, Tab Atkins Jr. wrote:
> >
> > I agree that it's an awful experience, especially because it turns the 
> > user's habits against them.  If the Nth item in the menu is ordinarily 
> > the UA's "Copy Link Location" and an app removes or re-orders items so 
> > that the Nth item changes to "Rotate", "Share", or "Delete," then 
> > users are in for a surprise when they make the automatic "Copy Link 
> > Location" gesture.
> 
> Gah, strongly agree.  Simple example - I use "Back" constantly in the 
> context menu, and would be really pissed if pages could easily kill 
> that.  I already get angry when I accidentally right-click a link and 
> just select the first option without looking closely.

I don't know what we can do about that. Authors definitely won't want 
their UI items to be below "Back". That would imply that leaving their 
site is more important than using their site's features.


> On Mon, Dec 31, 2012 at 12:54 AM, Jonas Sicking <jonas at sicking.cc> 
> wrote:
> > What I was saying as a browser vendor is that I don't think that 
> > authors are going to use this feature unless it provide the ability to 
> > replace the existing context menu. Or at least almost entirely replace 
> > it.
> 
> I don't think I can agree with this.

Well certainly if browsers don't implement it at all, they'll have a much 
bigger reason not to use it. :-)


> This argument would be more believable if authors currently used 
> pile-of-divs for context menus a lot, but I only rarely actually see it.  
> I think this is because it's just plain *hard* to do it even 
> half-decently.  The extreme ease with which authors will be able to 
> create high-quality context menus with <menu> will, I think, override a 
> lot of the concerns.

I see these kinds of context menus more and more, in particular in Web apps.

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