design-reviews#1242: Other Spec Review: HTML menu elements

#1242: Other Spec Review: HTML menu elements

Opened

Jul 1, 2026

Specification

https://whatpr.org/html/12011/interactive-elements.html#the-menubar-element from https://github.com/whatwg/html/pull/12011 although some aspects are a bit out of date relative to the explainer, which is more current

Explainer

https://open-ui.org/components/menu.explainer/

Links

Previous early design review, if any: none
An introduction to the feature, aimed at unfamiliar audiences: https://open-ui.org/components/menu.explainer/#introduction
A description of the problems that end-users were facing before this proposal: Menus on web sites often work in inconsistent ways and often in ways that do not serve the needs of users who depend on the keyboard or on assistive technology.
Alternatives considered: See the "General questions" section of the explainer and its many subsections.
Examples of how to use the proposal to solve the end-users' problems: https://open-ui.org/components/menu.explainer/#examples--code-snippets
What do the end-users experience with this proposal: Hopefully users will experience menus on the web that have more consistent patterns between sites in terms of supporting the same (and good) mouse behaviors, keyboard navigation and focus behavior, and exposure to assistive technology, and other accessibility characteristics.
User research you did to validate the problem and/or design, if any: none (though there were some points in the process where we did research about patterns used on existing sites to answer specific design questions, but I'd need to dig around to find it)
Web Platform Tests: https://wpt.fyi/results/html/semantics/menu/

The specification

Follows the Web Platform Design Principles.
Includes Security and Privacy Considerations sections based on answers to the Security/Privacy Questionnaire.

Where and by whom is the work is being done?

GitHub repo: https://github.com/openui/open-ui (explainer, issues) and https://github.com/whatwg/html/tree/menu-elements (spec, currently on branch)
Primary contacts:
- @dbaron, Google, current primary editor of explainer and PR
Organization/project driving the specification: Google
This work is being funded by: Google
Primary standards group developing this feature: OpenUI CG
Group intended to standardize this work: mostly WHATWG, a few small pieces (pseudo-classes/pseudo-elements) in CSSWG
Incubation and standards groups that have discussed the design:
- OpenUI CG has discussed many aspects of the proposal; see list
- CSSWG/WHATWG/OpenUI task force has discussed a few issues about pseudo-classes and pseudo-elements
- ARIA WG had a breakout discussing the proposal; see notes in https://github.com/w3c/aria/issues/2782
- Pointer Events WG has discussed click event retargeting, see minutes and https://github.com/w3c/pointerevents/pull/637
- WHATWG has discussed in https://github.com/whatwg/html/issues/11729
  - Note that at the https://github.com/whatwg/html/issues/12441 we discussed advancing the proposal to Stage 2. Some issues were raised (most significantly https://github.com/openui/open-ui/issues/1456) but I think the sense of the room is that once those were addressed (which at this point they mostly have been) the next request to advance to Stage 2 would likely succeed.

Also cc: other contributors @domfarolino @scottaohara @lukewarlow @josepharhar @mfreed7 @davidsgrogan

Feedback so far

Multi-stakeholder feedback:
- Chromium comments: https://chromestatus.com/feature/5206029088063488
- Mozilla comments: https://github.com/mozilla/standards-positions/issues/1317 Note Mozilla participants have been involved in some of the above standards discussions.
- WebKit comments: https://github.com/WebKit/standards-positions/issues/580 Note WebKit participants have been involved in some of the above standards discussions.
Major unresolved issues with or opposition to this specification:
- https://github.com/openui/open-ui/issues/1456 (calling this "unresolved" is a little questionable at this point -- I think we generally have agreement on it, and the Chromium prototype and the explainer are updated to mostly reflect that, but the spec PR is not yet updated so I wanted to call it out)
  - https://github.com/openui/open-ui/issues/1468 is a sub-point that came out of that that needs some further discussion
- https://github.com/openui/open-ui/issues/1312 (the Pointer Events WG didn't like what the OpenUI CG originally wanted. I think it should be easier to resolve the way the Pointer Events WG wants after the above nesting changes, but I haven't done so yet.)
Status/issue trackers for implementations: ChromeStatus (Mozilla TBD) (WebKit TBD)

You should also know that...

No response

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1242

Discussions

Discussed Jun 29, 2026 (See Github)

Matthew & Christian added.

Comment by @domfarolino Jul 1, 2026 (See Github)

Mozilla comments: https://github.com/mozilla/standards-positions/issues/NNN (TBD, will file request soon and edit). Note Mozilla participants have been involved in some of the above standards discussions.

WebKit comments: https://github.com/WebKit/standards-positions/issues/NNN (TBD, will file request soon and edit) Note WebKit participants have been involved in some of the above standards discussions.

Note that https://github.com/WebKit/standards-positions/issues/580 and https://github.com/mozilla/standards-positions/issues/1317 have already been filed.

Discussed Jul 6, 2026 (See Github)

Christian: Proposal to bring traditional desktop-app-style menus to the web. You can do some of this with HTML but it's super complicated. I think it's appealing because it's a real problem that developers need to solve. The explainer has many open questions that need to be resolved, so I'm not exactly sure what the review request is. I wantt to ask that, so we can carry on. First impression is the use case is valid.

Matthew: What's the web compat story about re-using <menu> (noting their reasoning on this). +1 to Christian asking what the bounds of the review are.

Luke: Sometimes there are questions in the OpenUI explainers that aren't questions that need to be answered. The framing can be: here's the thought process that lead to these answers. If TAG has feedback on some of the open questions that'd be valuable. There are some genuinely still open questions. If WHATWG like a certain approach then it'll be considered, but they're open to suggestions.

Luke: I suspect the webcompat situation is more serious than it may seem. Develoeprs may've been using it quite a bit. Maybe TAG could write something about using elements not for the semantic purpose they were intended? I think <menubar> is good.

Marcos: Agree with Matthew in case that sites can benefit from any existing semantics... worth investigating re-using/fixing the existing one if possible. Was surprsied to see new elements.

Luke: I think the existing semantics are quite different as is the CSS. So you'd need an attribute opt-in.

Lola: Sounds like Christian and Matthew doing more investigation, and we have surfaced some questions about why not use the current <menu> - can you draft an intiial comment?

Christian: Yes. Good use case, why don't you use <menu>, and what's the scope of the review.

Lola: Can definitely see the need and benefit of this process.

Luke: Earlier, there was talk about the concept of a navigation menu, with links as opposed to menu items. This was not looked upon favourably. Keyboard focus management, popovers, etc. issues. There's a separate proposal for site navigation 'menus' that may involve the <nav> element with an attribute - we should bear things in mind when considering this one.

Comment by @christianliebel Jul 10, 2026 (See Github)

@dbaron Thanks for bringing this to us! We haven’t done a deeper review yet. At first glance, this looks good. The use case is common and real.

Two questions came up so far:

What’s the scope of the review you’re looking for? The explainer still lists a number of open questions. Are you looking for the TAG’s input on resolving those, or at the design as it’s currently specified?
Why not build on the existing <menu> element rather than introducing new elements? We’d like to understand the reasoning here, including the web-compatibility considerations around reusing (or extending) what’s already there.

Thank you!

Comment by @dbaron Jul 10, 2026 (See Github)

What’s the scope of the review you’re looking for? The explainer still lists a number of open questions. Are you looking for the TAG’s input on resolving those, or at the design as it’s currently specified?

I think mostly on the design as currently specified. The explainer has definitely been a living document over the course of the development of this feature. A few weeks ago I attempted to edit the explainer to try to document the settled status of many of the things discussed there, but it's entirely possible I missed some things. (I think I also intentionally left some things in an unsettled state because we might want to do them in later revisions even if they're not happening as part of what we hope to initially ship.)

(That said, I plan to land some edits (already half written) to the explainer (hopefully) today to respond to https://github.com/whatwg/html/issues/11729#issuecomment-4923664859 as discussed in https://github.com/openui/open-ui/issues/1189#issuecomment-4928386129 -- though I'm not particularly interested in even more input on that issue as it's already gotten quite a bit.)

Why not build on the existing <menu> element rather than introducing new elements? We’d like to understand the reasoning here, including the web-compatibility considerations around reusing (or extending) what’s already there.

There's some prior discussion of this in https://open-ui.org/components/menu.explainer/#why-not-reuse-the-menu-element and https://github.com/openui/open-ui/issues/1194 but I think the short answer is that changing the behavior of something that's been part of HTML for >30 years adds a lot of risk to the project. I also recall @scottaohara saying something specific about the implications on existing behavior of ATs for <menu> although I don't remember the details.