[Feature Request] lion/menu component

[jmcgavin]

Menu component

I'd like to propose a lion-menu component be added to the set of Navigation components.

Aesthetically similar to a dropdown menu or lion-select-rich. The purpose of this component would be to navigate between a variable number of views of equal or differing importance.

Implementations of lion/menu should adhere to https://www.w3.org/TR/wai-aria-practices-1.1/#menu

API

<lion-menu has-arrow> // extends @lion/overlays/OverlayMixin. Optional has-arrow property
  <lion-button slot="invoker">Open</lion-button> // or whatever invoker you want
  <lion-menu-content role="menu" slot="content">
    <lion-menu-item role="none">Main menu</lion-menu-item> // will act as a label and is not focusable
    <lion-menu-item role="separator"></lion-menu-item> // not focusable
    <lion-menu-item role="menuitem">New</lion-menu-item>
    <lion-menu-item role="menuitem">Open</lion-menu-item>
    <lion-menu-item role="menuItem" disabled>Save</lion-menu-item> // extends @lion/core/DisabledMixin
    <lion-menu-item role="menuitem">Close</lion-menu-item>
    <lion-menu-item role="separator"></lion-menu-item>
    <lion-menu-item role="menuitem">Logout</lion-menu-item>
  </lion-menu-content>
</lion-menu>

[erikkroes]

It might be nice to investigate a "menu" with links (which should not be menuitems), and one with both links and menuitems at the same time. They're technically very comparable, and offering these would give users alternatives when a "menu" might not be the best fit.

[MathieuPuech]

in aria example of menubar, there is links with role="menuitem".

We could have something like that:

<lion-menu>
  <button slot="invoker">Open</button>
  <lion-menu-content role="menu" slot="content">
    <a href="/link1" role="menuitem">Link 1</a>
    <a href="/link2" role="menuitem">Link 2</a>
    <button @click="${()=>{}}" role="menuitem">Action 1</a>
  </lion-menu-content>
</lion-menu>

The only thing is that the slotted anchors can't have a mixin applied (like DisabledMixin). But the disabled state can maybe be handled by the lion-menu-content custom-element.

[jmcgavin]

To be more accommodating, lion-menu-content's children could be slots rather than customElements. This would permit anchors, buttons, divs, spans, etc. But it remains to be seen if lion-menu-content can handle the disabled states

[gerjanvangeest]

Hi all,

We have researched/discussed this quickly within the team and came up with the following:

Accessible Examples

• Menubar with links
• Menubar with radio/checkboxes
• Menu-button with links
• Menu-button with buttons
• Disclosure-navigation with links

The first 4 are aligned with each other, so we will end up with something like:

<div class="menu_button">
  <button type="button"
          id="menubutton"
          aria-haspopup="true"
          aria-controls="menu2">
    WAI-ARIA Quick Links
  </button>
  <ul id="menu2"
      role="menu"
      aria-labelledby="menubutton">
    <li role="none">
      <a role="menuitem"
         href="https://www.w3.org/"
         tabindex="-1">
        W3C Home Page
      </a>
      [...]
    </li>
  </ul>
</div>

All examples only allows either buttons or anchors, since it can be confusing for the users when mixing them.
We should throw an error is they are mixed.

API

<lion-menu>
  <button slot="invoker">Open</button>
  <lion-menu-content slot="content">
    <a menu-type="menu-item" href="/link1">Link 1</a>
    <a menu-type="menu-item" href="/link2" >Link 2</a>
    <hr menu-type="separator">
    <a menu-type="menu-item" href="/link3" >Link 3</a>
  </lion-menu-content>
</lion-menu>

Or

<lion-menu>
  <button slot="invoker">Open</button>
  <lion-menu-content slot="content">
    <button menu-type="menu-item" @click="${()=>{}}">Action 1</button>
    <button menu-type="menu-item" @click="${()=>{}}">Action 2</button>
  </lion-menu-content>
</lion-menu>

API possible 2nd iteration

<lion-menu>
  <lion-button slot="invoker">Open</ing-button>
  <lion-menu-content slot="content">
    <lion-menu-submenu label="sub list" menu-type="menu-item">
      <a href="/link1" menu-type="menu-item">Link 1</a>
      <a href="/link2" menu-type="menu-item">Link 2</a>
    </lion-menu-submenu>
    <a href="/link3" menu-type="menu-item">Link 3</a>
  </lion-menu-content>
</lion-menu>

Technical details

• Make use of (local) overlay system
• Keyboard interaction/roles/aria-attributes are mentioned under Accessible Examples
• disabled anchors do not exist, so this will only be possible for buttons

[MathieuPuech]

the submenu could maybe be done by recursion with <lion-menu>?

<lion-menu>
  <button slot="invoker">Open</button>
  <lion-menu-content slot="content">
    <lion-menu menu-type="menu-item">
      <button slot="invoker">sub list</button>
      <lion-menu-content slot="content">
        <a menu-type="menu-item" href="/link1">Link 1</a>
        <a menu-type="menu-item" href="/link2" >Link 2</a>
      </lion-menu-content>
    </lion-menu>
    <hr menu-type="separator">
    <a menu-type="menu-item" href="/link3" >Link 3</a>
  </lion-menu-content>
</lion-menu>

And why using in your examples menu-type attribute instead of the role attribute?

[gerjanvangeest]

Our main a11y expert @erikkroes is on holiday, but he is in big favour of the Disclosure-navigation with links, which would also work for buttons. See below email:

• When using links, I would not use the menuitem-role. It is advised against for links, even though it's in the wai aria practices. A bit confusing, but probably better to avoid. It also means removing the role="menu", and maybe also aria-haspopup (as it says "menu" with some screen readers). Aria-expanded on the invoker would be useful for both links and buttons.
• Role="presentation" has better support than "none", so I'd rather pick that.
• I don't quite follow the tabindex="-1" on the links. Why are interactive elements not focusable? I assume something else is managing focus? Would be very interesting to test. Maybe even a user test.

I do think a menu would be reaaally good to have in the system. Looking forward to have it added.

Now back to vacation!

-Erik

This will also simplify the internal code for the menu.

@MathieuPuech

• lets leave the submenu out of scope for now. But yes would be nice to reuse the same component.
• We removed the roles (since we can set them directly), added slots (which would not keep the right DOM order for separators) and changed the slots that to an attribute menu-type, maybe we could have gone back to roles :). But then if we would have wanted to change the internal a11y behaviour we would have to do a breaking change.

[daKmoR]

another reason why menu-type make sense it that in the beginning, we will only support menu-item and separator... so not every role will be there... which might be confusing if we use role.

One thing we didn't discuss yet is how will this look on mobile? 🤔 bottom sheet?

[MathieuPuech]

Menu exists on mobile too (in material design for example).

But I suppose the menu actions could be replaced by a bottom sheet on mobile. I suppose it depends on the use case.

[MathieuPuech]

on iOS, there is Pull-down menus too.

[jmcgavin]

I'm in favour of a menu implementation on mobile rather than bottom sheet

[jmcgavin]

I have something already started and I could open a pull request. Let me know if I have the go ahead

[daKmoR]

please go ahead - best would be with tests only so we can focus on the public API 👍

but a demo/proof of concept is always helpful as well 🤗

[MathieuPuech]

Added a draft PR here: #1027

[abdonrd]

There is no news about this, right?

[tlouisse]

Hi @abdonrd, this is a branch we have been working on in the past: https://github.com/ing-bank/lion/tree/feat/manyMenus

I hope that there will be some incentive/need in our personal extension layer to wrap this up in the future :)