nested structure for menus?
Nobody has claimed this yet.
- Dominant language
- MDX
- Stars
- 4.5k
- Forks
- 226
- Avg merge
- 2d 22h
- Merged PRs (30d)
- 4
Description
The biggest concern that came up when discussing advancing the menu elements proposal to stage 2 in the WHATWG is the non-nested structure of the menu elements (using idrefs). See https://github.com/whatwg/html/issues/11729#issuecomment-4621448600 and following comments. The main concern seems to be relationship to existing web features (such as event dispatch) that depend in various ways on nesting.
My understanding is that the structure we're currently using matches more of the existing libraries that were evaluated while developing the proposal.
So I'm opening this issue to try to figure out:
- if we went with a nested structure, what would it look like
- what advantages/disadvantages would that nested structure have.
I'll start with what seems to me like a reasonable way to build nested menus.
Consider a simple example the structure we have today:
<menubar>
<menuitem command=toggle-menu commandfor=file-menu>File</menuitem>
<menuitem command=toggle-menu commandfor=edit-menu>Edit</menuitem>
</menubar>
<menulist id=file-menu>
<menuitem>New</menuitem>
<menuitem>Open</menuitem>
</menulist>
<menulist id=edit-menu>
<menuitem>Cut</menuitem>
<menuitem>Copy</menuitem>
<menuitem>Paste</menuitem>
</menulist>
If I were to turn this into a nested structure, I think I'd turn it into something like this. (For now, please focus comments on the structure and not on the names!)
<menubar>
<submenu>
<menulabel>File</menulabel>
<menulist>
<menuitem>New</menuitem>
<menuitem>Open</menuitem>
</menulist>
</submenu>
<submenu>
<menulabel>Edit</menulabel>
<menulist>
<menuitem>Cut</menuitem>
<menuitem>Copy</menuitem>
<menuitem>Paste</menuitem>
</menulist>
</submenu>
</menubar>
In this proposal, the <menulabel> would be much like a <menuitem> (and it could even be one -- again, please ignore naming for now), but it would be the item that opens the submenu. I think it needs to be in a child element of the <submenu> so that events and states (e.g., :hover) going to the label can be distinguished from those going to the submenu's <menulist>.
If we were to consider nested menu structure, does this seem like the right way to do it? Are there other alternatives we should consider? (Are there existing libraries that use a nested menu structure, and if so, what do they do?)
If we did this, what advantages and disadvantages would it have? Would there be issues with ARIA mappings? Are there other things we should consider?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by comparing the current idref-based menu markup with the proposed nested HTML structure in this issue, then read the linked WHATWG discussion. Investigate existing nested-menu libraries and the potential event, state, and ARIA-mapping implications; done means documenting the viable alternatives and their advantages and disadvantages.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- html
- Domain
- accessibility, frontend, web-dev
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100