Update menu explainer #1215
Open
Update menu explainer #1215
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR is a bunch of suggested changes / clarifications for the content of the explainer. Fleshing out some ideas, updating some alt text to be more accurate, stuff like that. There is no associated issue for this work.
scottaohara
requested review from
domfarolino,
dizhang168,
josepharhar and
mfreed7
as code owners
scottaohara
commented
May 13, 2025
hidde
reviewed
May 13, 2025
|
|
||
| The `<select>` element is a form-associated element and contains `<option>` elements. Each of these `<option>` elements must have a server-readable value. As a user chooses an option, specific events are triggered (change, input) and a new value is set. | ||
|
|
||
| On the other hand, the proposed `<menulist>` element should be used to display a list of commands/actions. Each `<menuitem>` should be thought of as a command that is activable. That action could be to open a new nested menulist element or to trigger a specific command. It must adhere to [ARIA guidelines for menu and menubar](https://www.w3.org/WAI/ARIA/apg/patterns/menubar/). | ||
| On the other hand, the proposed `<menulist>` element should be used to display a list of commands/actions. Each `<menuitem>` should be thought of as a command that is activable. That action could be to open a new nested menulist element or to trigger a specific command. It is not generally expected for the invoking element's value or visible label to be modified when activating a `<menuitem>`. It must adhere to ARIA guidelines for [menu and menubar patterns](https://www.w3.org/WAI/ARIA/apg/patterns/menubar/). |
There was a problem hiding this comment.
not part of your change, but I don't think “activable” is a word? And it's not very clear what “command that is activable” is. Maybe we can fix at the same time
Suggested change
| On the other hand, the proposed `<menulist>` element should be used to display a list of commands/actions. Each `<menuitem>` should be thought of as a command that is activable. That action could be to open a new nested menulist element or to trigger a specific command. It is not generally expected for the invoking element's value or visible label to be modified when activating a `<menuitem>`. It must adhere to ARIA guidelines for [menu and menubar patterns](https://www.w3.org/WAI/ARIA/apg/patterns/menubar/). | |
| On the other hand, the proposed `<menulist>` element should be used to display a list of commands/actions. Each `<menuitem>` should be thought of as performing a specific action. That action could be to open a new nested menulist element or to trigger a specific command. It is not generally expected for the invoking element's value or visible label to be modified when activating a `<menuitem>`. It must adhere to ARIA guidelines for [menu and menubar patterns](https://www.w3.org/WAI/ARIA/apg/patterns/menubar/). |
dizhang168
approved these changes
May 20, 2025
| * In a menulist, a menuitem's most common purpose is to invoke actions (commands) or other submenus (menulists). | ||
| * Menulists are commonly rendered as a **popover**. Submenus are also commonly rendered as adjacent popovers on larger viewports. | ||
| * On smaller viewports, submenus may overlay or replace the higher-level menulist from which they were invoked. | ||
| * A "back" menuitem may be rendered to allow a user to "navigate up" to the higher-level menulist. |
There was a problem hiding this comment.
Great idea. I have seen such use cases especially for mobile web app, where there isn't enough space to show multiple nested submenus (or to have better UX).
|
|
||
| **Question: Is `<fieldset>` necessary to group `<menuitem>` together?** | ||
| **Question:** are the `open` or `name` attributes needed for `menubar` or `menulist`? | ||
| ??? |
There was a problem hiding this comment.
The open attribute is useful if we want to default the menulist as open. But maybe we should avoid that, and be explicitly to only open with user activation behaviors. It is definitely not necessary on menubar.
The name attribute is meant to group radio menuitem elements together. It is probably not necessary for menubar and menulist.
|
|
||
| The `<select>` element is a form-associated element and contains `<option>` elements. Each of these `<option>` elements must have a server-readable value. As a user chooses an option, specific events are triggered (change, input) and a new value is set. | ||
|
|
||
| On the other hand, the proposed `<menulist>` element should be used to display a list of commands/actions. Each `<menuitem>` should be thought of as a command that is activable. That action could be to open a new nested menulist element or to trigger a specific command. It must adhere to [ARIA guidelines for menu and menubar](https://www.w3.org/WAI/ARIA/apg/patterns/menubar/). | ||
| On the other hand, the proposed `<menulist>` element should be used to display a list of commands/actions. Each `<menuitem>` should be thought of as a command that is activable. That action could be to open a new nested menulist element or to trigger a specific command. It is not generally expected for the invoking element's value or visible label to be modified when activating a `<menuitem>`. It must adhere to ARIA guidelines for [menu and menubar patterns](https://www.w3.org/WAI/ARIA/apg/patterns/menubar/). |
There was a problem hiding this comment.
nit: I wrote ARIA guidelines originally, but that is wrong. Should be changed to APG recommendations.
Co-authored-by: Hidde de Vries <[email protected]>
Co-authored-by: Hidde de Vries <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is a bunch of suggested changes / clarifications for the content of the explainer. Fleshing out some ideas, updating some alt text to be more accurate, stuff like that.
There is no associated issue for this work.