Joey Arhar

I opened an HTML PR which should solve the bug without the need for adding the DOM hook this PR adds: https://github.com/whatwg/html/pull/9457

I believe that we should keep selectmenu as is and not copy/clone/slot anything from the selected option into the selected value slot. Copying innerHTML seems error prone and could lead...

> as it stands at the moment, the change event won't cause the selectmenu to update when using keyboard(arrow) navigation to toggle between the options If you're talking about changing...

I talked to @mfreed7 and @domenic about what our options are to solve this, and this is what we came up with. TL;DR I think that we should have the...

The plan is still to use clonenode to copy the contents of the selected `` into ``

In the codepen, I can see the options being rendered in the selectmenu's dropdown, but clicking on them does not appear to change the selected option. Is that the bug?

I don't think this is an easy to support use case. The selectmenu implementation uses child/descendant changes as a hook to look for new option elements, in addition to custom...

Upon further investigation, it looks like the selectmenu implementation in chromium is already watching for all DOM changes in the document anyway when looking for child options and button/selected-value/listbox parts,...

Here is a minimal example of the use case we're trying to support: ```html one two ```

I thought that slotting in other parts might not be a thing you can do with shadowdom, but lets see if this example works: ```html doubly named slotted element ```...