openui / openui/open-ui

nested structure for menus?

Open
#1,456 5 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

menu
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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.