Pare down menu and command machinery to what will be implemented #237

domenic · 2015-10-07T15:10:24Z

Consider all of the following:

HTMLMenuElement
HTMLButtonElement.prototype.menu / menu content attribute / <button menu="id">
HTMLElement.prototype.contextMenu / contextmenu content attribute
<menu type="contextmenu"> functionality (renamed in Rename <menu type=popup> to <menu type=context> #235)
- HTMLMenuItemElement
<menu type="toolbar"> functionality
The "command" concept
- Uniformizing menu items, buttons, and links as a spec-level device (this is probably a good thing, unless it drastically contradicts implementations)
- The command API (removed in Remove some unimplemented menu and command features #244)
- document.commands (removed in Remove some unimplemented menu and command features #244)
- master/slave commands via <menuitem command=""> (removed in Remove some unimplemented menu and command features #244)

Which of these are actually on track to be implemented? I know Gecko has some implementation of menu stuff, although based on an older spec. And Blink has a behind-a-flag implementation of contextmenu, and maybe more.

I am especially interested in <menu type="toolbar"> and the command API. Are they implemented anywhere, or on track to be implemented? If not, we could remove a decent amount of extra complication.

The text was updated successfully, but these errors were encountered:

sanjoypal · 2015-10-08T05:52:31Z

I don't see any point implementing type=toolbar. Javascript libraries are enough for this purpose. Also, I am not sure how useful the command API is. We don't have implementation of command API in blink.

domenic · 2015-10-08T15:56:44Z

Cool, thanks @sanjoypal. @smaug----, what are your thoughts?

annevk · 2015-10-09T07:10:11Z

Paging @sicking.

sicking · 2015-10-09T07:42:29Z

I think the whole command stuff is overly complex and better handled by the page itself.

Beyond that, we really need input from developers what they need. For example, I don't think it's useful to implement anything that can't be styled by authors. It simply won't get used.

These days I'm more of the opinion that whatever we do is likely a waste of time. We should just ship web components and let libraries evolve something that authors like. If we need primitives we can always add those, for example aria attributes to support accessibility.

The one thing that might be hard to add primitives for is to enable pages to create a menu that goes outside of the browser/iframe rendering area. That would be the main reason to do anything here at all I think. But again, if it can't be styled, it likely won't get used.

Anyhow, I think starting by asking browser vendors here is the wrong end. I'd recommend reaching out to library/framework authors and get their thoughts.

domenic · 2015-10-09T17:23:22Z

Well, I generally align with the waste of time idea. But we're on the verge of two interoperable implementations of at least some subset of this, so I want to keep that specced and pare down the rest.

It sounds like at least <menu type="toolbar"> can be removed, and probably the command API. For the rest, I'll probably have to roll up my sleeves and do some testing on Gecko and Blink-with-the-flag-flipped to see what's left.

This removes the command API properties commandType, commandLabel, commandIcon, commandHidden, commandDisabled, and commandChecked. It also removes document.commands. These were not implemented anywhere, and per #237, were not on track to be implemented. Without these APIs, the command facets Type, ID, Hint, Icon, and Checked State are no longer used by the specification. (The remaining facets, viz. Label, Access Key, Hidden State, Disabled State, and Action, are still used, mostly by the accesskey specification.)

The spec contains a provision wherein <menuitem>s can have command="" attributes which contain the ID of another command that they delegate to. This has not been implemented in either of the two engines which have implemented menu items. Part of #237.

domenic · 2015-10-09T21:39:50Z

Still to-investigate after #244:

HTMLButtonElement.prototype.menu / menu content attribute / <button menu="id">. Does this work anywhere? If not, then we should probably get rid of it, as it'll be un-stylable and of limited use. In that case we can rename "popup" to context throughout the spec.
<menu type="toolbar">. What actual implementation requirements does the spec give for this? I am beginning to think that all the spec's content on this is basically author/checker facing, in that it tells you that you can combine <menu type="toolbar"> and <li> in various ways as a semantic tool, instead of using <ul> like people often do. If that's the case, we can probably leave it in. More investigation needed.

annevk · 2015-10-10T08:48:23Z

Note that <button menu> goes with <button type=menu>, the latter of which definitely seems to do something in Firefox.
"toolbar" used to be something special, but that got removed. Now it's simply the default value and indicates the element is another list/grouping element of sorts. So yeah, nothing fancy.

This removes the command API properties commandType, commandLabel, commandIcon, commandHidden, commandDisabled, and commandChecked. It also removes document.commands. These were not implemented anywhere, and per #237, were not on track to be implemented. Without these APIs, the command facets Type, ID, Hint, Icon, and Checked State are no longer used by the specification. (The remaining facets, viz. Label, Access Key, Hidden State, Disabled State, and Action, are still used, mostly by the accesskey specification.)

The spec contains a provision wherein <menuitem>s can have command="" attributes which contain the ID of another command that they delegate to. This has not been implemented in either of the two engines which have implemented menu items. Part of #237.

domenic · 2017-01-27T17:35:08Z

Note that <button menu> goes with <button type=menu>, the latter of which definitely seems to do something in Firefox.

@annevk, can you create a live-dom-viewer or jsbin example? I can't reproduce anything working using e.g. the example from the spec: http://jsbin.com/bagosurebu/edit?html,output

annevk · 2017-01-29T11:51:02Z

If you render <button type=menu>test</button> you don't get a button, but you get something that looks like a dropdown (that doesn't function). I'm not sure how it works or can be made to work though.

smaug---- · 2017-01-29T23:25:50Z

I'm getting very much like normal button, and .type says "submit", in FF.
And I'm not seeing menu type in http://searchfox.org/mozilla-central/rev/8fa84ca6444e2e01fb405e078f6d2c8da0e55723/dom/html/HTMLButtonElement.cpp#46-50

http://searchfox.org/mozilla-central/source/testing/web-platform/tests/html/semantics/forms/the-button-element/button-validation.html
fails, per http://searchfox.org/mozilla-central/source/testing/web-platform/meta/html/semantics/forms/the-button-element/button-validation.html.ini

annevk · 2017-01-30T08:55:39Z

Is what I see in Firefox on macOS. type does return "submit".

smaug---- · 2017-01-30T10:25:09Z

Where is that coming from. Do we get wrong native styling or something?
@mstange is using OSX

This should go to some Gecko bug, but
http://searchfox.org/mozilla-central/rev/8fa84ca6444e2e01fb405e078f6d2c8da0e55723/widget/nsNativeTheme.cpp#221-230
http://searchfox.org/mozilla-central/rev/8fa84ca6444e2e01fb405e078f6d2c8da0e55723/widget/cocoa/nsNativeThemeCocoa.mm#2478,2497-2498
And only Mac styling is using that http://searchfox.org/mozilla-central/search?q=IsButtonTypeMenu&path=

dpogue · 2017-01-30T18:23:00Z

As a web developer, I would love to see <button type="menu" menu="id"> actually supported in some browsers. I feel like supporting <menu type="context"> is missing half its intended functionality if there's no way to show the menu except via right-click.

There's no way to use JavaScript to fully mimic <button type="menu"> because you cannot fake a contextmenu event on the button to present the menu, and <menu type="context"> can't be styled to be visible in the page.

annevk · 2017-01-31T09:48:53Z

@smaug---- I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1335337. My concern no longer blocks this bug.

@dpogue that might be worth filing a new issue on. If there's a native thing you cannot emulate there might be more interest in adding something to get there.

domenic · 2017-02-08T22:35:41Z

I'm looking into this more. We can definitely remove <button type="menu">, but once we do that, <menu type="toolbar"> starts looking pretty useless. I started trying to hack together some acceptable CSS to make the spec's example uses of it look reasonable and it's just a mess. I'm going to remove it entirely; authors can use lists and such.

Edit: meh, I guess as long as I don't try to make the spec's examples work, we can leave it as an alternative to <ol> and <ul>.

zcorpan · 2017-02-09T13:57:25Z

It seems menu type=toolbar as some usage in the wild, so might as well keep it...

httparchive (~500,000 pages): 304 matches
GitHub search: ~20,000 matches

This removes the type="menu" option for buttons, which has wide-reaching consequences for the menu infrastructure. It was intended that <menu type="context"> (originally <menu type="popup">) would be used both for context menus, and for popup menus triggered by buttons. Only the context menu case was ever implemented (in Gecko and, behind a flag, in Blink). As such, removing support for the triggered-by-button case allows us to remove a lot of now-unnecessary abstraction; for example, we can rename the "popup menu state" to the "context menu state" to match the type="context" content attribute. And we can relocate all of the processing model for constructing menus into the context menu processing model section. Finally, we can clearly state for authors that the <menu> element has two distinct uses: for customizing the context menu (type="context"), and as a semantic alternative to <ul> for a list of commands (type="toolbar"). This fixes #237, although we still need to keep an eye on the entire context menu feature since its cross-browser support is on the low side.

Since whatwg/html#237 there are almost no UA requirements for <menu type=toolbar> (basically just reflection), so there is no reason to warn about its use.

This removes the type="menu" option for buttons, which has wide-reaching consequences for the menu infrastructure. It was intended that <menu type="context"> (originally <menu type="popup">) would be used both for context menus, and for popup menus triggered by buttons. Only the context menu case was ever implemented (in Gecko and, behind a flag, in Blink). As such, removing support for the triggered-by-button case allows us to remove a lot of now-unnecessary abstraction; for example, we can rename the "popup menu state" to the "context menu state" to match the type="context" content attribute. And we can relocate all of the processing model for constructing menus into the context menu processing model section. Finally, we can clearly state for authors that the <menu> element has two distinct uses: for customizing the context menu (type="context"), and as a semantic alternative to <ul> for a list of commands (type="toolbar"). This fixes whatwg#237, although we still need to keep an eye on the entire context menu feature since its cross-browser support is on the low side.

domenic added the removal/deprecation Removing or deprecating a feature label Oct 7, 2015

domenic mentioned this issue Oct 9, 2015

Remove some unimplemented menu and command features #244

Merged

annevk mentioned this issue Mar 31, 2016

menu element, why no love? #971

Closed

domenic mentioned this issue Jul 18, 2016

<button> shouldn't have activation behavior when it is not in a form #1567

Open

domenic mentioned this issue Jan 27, 2017

Discussion/Question about the usefulness of the menu element with type context #2304

Closed

domenic self-assigned this Feb 8, 2017

This was referenced Feb 8, 2017

Remove <button type=menu> #2342

Merged

Add tests for the removal of <button type=menu> web-platform-tests/wpt#4769

Merged

domenic closed this as completed in #2342 Feb 9, 2017

zcorpan added a commit to zcorpan/validator that referenced this issue Mar 20, 2017

Allow <menu type=toolbar> without warning

1315cbd

Since whatwg/html#237 there are almost no UA requirements for <menu type=toolbar> (basically just reflection), so there is no reason to warn about its use.

zcorpan mentioned this issue Mar 20, 2017

Allow <menu type=toolbar> without warning validator/validator#477

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Pare down menu and command machinery to what will be implemented #237

Pare down menu and command machinery to what will be implemented #237

domenic commented Oct 7, 2015

sanjoypal commented Oct 8, 2015

domenic commented Oct 8, 2015

annevk commented Oct 9, 2015

sicking commented Oct 9, 2015

domenic commented Oct 9, 2015

domenic commented Oct 9, 2015

annevk commented Oct 10, 2015

domenic commented Jan 27, 2017

annevk commented Jan 29, 2017

smaug---- commented Jan 29, 2017

annevk commented Jan 30, 2017 •

edited

Loading

smaug---- commented Jan 30, 2017

dpogue commented Jan 30, 2017

annevk commented Jan 31, 2017

domenic commented Feb 8, 2017 •

edited

Loading

zcorpan commented Feb 9, 2017

Pare down menu and command machinery to what will be implemented #237

Pare down menu and command machinery to what will be implemented #237

Comments

domenic commented Oct 7, 2015

sanjoypal commented Oct 8, 2015

domenic commented Oct 8, 2015

annevk commented Oct 9, 2015

sicking commented Oct 9, 2015

domenic commented Oct 9, 2015

domenic commented Oct 9, 2015

annevk commented Oct 10, 2015

domenic commented Jan 27, 2017

annevk commented Jan 29, 2017

smaug---- commented Jan 29, 2017

annevk commented Jan 30, 2017 • edited Loading

smaug---- commented Jan 30, 2017

dpogue commented Jan 30, 2017

annevk commented Jan 31, 2017

domenic commented Feb 8, 2017 • edited Loading

zcorpan commented Feb 9, 2017

annevk commented Jan 30, 2017 •

edited

Loading

domenic commented Feb 8, 2017 •

edited

Loading