For completion, there have been solutions to semantically enable navigational menus in the past with only HTML and CSS and/or server response without JS:

• Using nested <ul><li><a href="…">…</a><ul><li><a href="…"> solutions where the dropdowns are shown on CSS display and :hover/:focus for CSS only approximation of such elements. (repeated from Slack thread)
• select could be used for navigation purposes as well when bound to a form element and server response. In OOUI we provide DropdownInputWidget for such and other cases

@Volker_E can you clarify your thoughts around adding this to the list of examples? as far as I understand it is a select menu, whereas this task is about navigational menus

dropdowns

As I've explained in my last comment in T311270 I don't agree with using link (blue text with underlined when hover) for items that are not text links within text/paragraph. I think this behavior should be reserved for links within block texts (e.g. links within the article) instead of using it for clickable items.

I think for this menu trigger we should use the quiet dropdown button we already have in our system instead of adding an arrow ⌄ in all links.

In T311306#8030437, @bmartinezcalvo wrote:

As I've explained in my last comment in T311270 I don't agree with using link (blue text with underlined when hover) for items that are not text links within text/paragraph. I think this behavior should be reserved for links within block texts (e.g. links within the article) instead of using it for clickable items.

I think for this menu trigger we should use the quiet dropdown button we already have in our system instead of adding an arrow ⌄ in all links.

This proposal does not specify the color of the menu handle/trigger, it just specifies the use of a ⌄ icon, and non-bold font.

Even though being seen next to the tabs make this look as a little disharmonious, ultimately IMO it makes sense to make this element bold in keeping with standard button style, as this is an action to trigger an overlay menu, which is somewhat different from details/summary, where summary is part of the details element.

I agree that the menu handle/triggers are buttons (specifically "navigational menu buttons").
"Dropdown" or <select> elements are usually used to select options, and usually shouldn't contain links or other interactive content. The <summary> element is typically used in cases like FAQs, or with hidden text. The <input> element in the typeahead search is most similar to a combobox with autocomplete, which also distinct from everything else.

Something to note, I think it can be confusing to compare styling based on native HTML elements, because the HTML used is often an implementation detail. What actually matters is how we define a particular UI element, i.e. it can be clarifying to refer to the ARIA web pattern when talking about UI elements. For example, we use the checkbox hack to implement Vector's "navigation menus", meaning the <input> is styled and coded to be a "menu button". Alternatively you could use <summary>/<details> to implement a "navigation menu", but it should still be consistent so the <summary> should look and behave a button. On a similar note, ARIA definitions help differentiate components that look similar. The native <select> element and combobox pattern look nearly identical, but they have different requirements that impact the nuances of the design, and shouldn't be compared 1 to 1.