How to support interactive content like `<input type=search>` in a menu?

[domfarolino]

The menu elements explainer (which I'm currently rewriting) mentions supporting <input type=search> a few times, as an example of other interactive content that can be a sibling to <menuitem> elements inside of <menulist>, and maybe even <menubar>.

This prompts at least three questions:

• Should we even support this? I don't think it's a common pattern on the web, but some heavier applications like Google Docs support it. Should we leave it to them to support? If we decide to support it natively, how far should we go? Should we consider what we discussed with combobox, which is maybe to support some native search mechanism out-of-the-box that searches through menu items in all of the popover-linked menu lists?
• What are the accessibility implications of this? Are screen readers generally compatible with encountering an input element in an application menu? macOS does this natively, so presumably the accessibility story is sane and well-thought-out.
• What about other interactive content (besides links of course!)? Do we need to do anything special if other interactive content is embedded in a menubar or menulist?

[josepharhar]

I don't think that we should support interactive content like this, even though there are some examples of menus that do it. Google docs does a nice alternative where there's a search menuitem which opens a separate popup/dialog which has a text field in it.

[frehner]

Hm, I think it's a common pattern to have a Menu with a Search field in it; though, perhaps what is actually implemented is a popup that contains a search field with a menu next to it, and not a part of it? e.g. React Aria autocomplete https://react-aria.adobe.com/Autocomplete seems to have it next to, and not inside