During an earlier meeting we discussed multi-select for <selectmenu>, and ended up resolving that we should work on specifying a <listbox> element to use for <selectmenu>'s listbox popup.

I want to clarify whether this is going to conflict with one of our early requirements for <selectmenu>, which is that authors can fully customize the contents of a select.

We had clear feedback that one of the main things keeping developers from using the browser's native controls is the lack of control over their content, including the ability to add arbitrary markup. So (speaking for the Edge web platform team here) we would not have a lot of interest in implementing a <selectmenu> that fails to meet this requirement.

Thus if we're using a new <listbox> element for the <selectmenu>'s dropdown, <listbox> would need to allow arbitrary HTML content.

There is a tension here with the <listbox>'s default ARIA role. The listbox role expects that all of its children have the option role, but if developers can include arbitrary content in the listbox then this will not necessarily be the case.

I think this is OK. For most use cases of <selectmenu>, the default listbox aria role will be appropriate for its <listbox>. If a developer builds something more outlandish -- for example a <selectmenu> whose dropdown contains other controls -- then it is the developer's responsibility to specify an appropriate ARIA role.

This will be better than the current state of things where listboxes and select dropdowns are built "by hand" out of <div>s where accessibility is completely dependent on the developer even for very simple re-implementations of these controls.

So, is it OK for the <listbox> to allow arbitrary HTML content? It seems that it must do so in order to support our goal of allowing authors to specify arbitrary HTML for <selectmenu>.