[whatwg] <menu> and friends

[Jonas Sicking]

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.

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

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

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.

What the default mode should be I care less about. But I would note
that using as default whatever we think is the more user friendly
option is likely a good idea.

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

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

>> Note that I didn't say "always" but "many cases". I do think it's the
>> case that in many cases displaying the UA menuitems is desirable. A good
>> example of this is menu items that control access to the clipboard since
>> that's something that webpages can't implement themselves. Most browsers
>> do not permit reading and writing to the clipboard arbitrarily.
>
> Aren't those items accessible from the main menu?

Yes, though I think they are used commonly enough from the context
menu that it'd bother users a lot if we removed it from the context
menu of editable text.

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

/ Jonas