[select] It's very unclear what actual API surfaces are introduced by this proposal

[domenic]

https://open-ui.org/components/selectmenu/#anatomy-of-the-selectmenu seems to imply the introduction of 4 new HTML elements: <button>, <selected-value>, <marker>, and <listbox>. It also lists the existing <option> and <optgroup> elements, and then it also lists the <select> element---probably that's a typo for <selectmenu>, so that would be a 5th new element?

And the diagram lists opt-group, not optgroup, so I'm not sure what's going on there.

But then if you check "show slots" we also get a button-container and listbox-container slot. And a few slots that have the same name as their child elements. And then an unnamed slot between listbox and opt-group. I guess this slot-versus-element issue is related to #702.

This explainer would significantly benefit from a clear listing of the proposed API surfaces, including:

• New elements
• New special content attributes (behavior=""??) or ways of modifying the behavior of existing content attributes (slot="")
• What special values the content attributes can have

[josepharhar]

https://open-ui.org/components/selectmenu/#anatomy-of-the-selectmenu seems to imply the introduction of 4 new HTML elements: <button>, <selected-value>, <marker>, and <listbox>. It also lists the existing <option> and <optgroup> elements, and then it also lists the <select> element---probably that's a typo for <selectmenu>, so that would be a 5th new element?

And the diagram lists opt-group, not optgroup, so I'm not sure what's going on there.

But then if you check "show slots" we also get a button-container and listbox-container slot. And a few slots that have the same name as their child elements. And then an unnamed slot between listbox and opt-group. I guess this slot-versus-element issue is related to #702.

Hopefully #710 addresses all of this

New special content attributes (behavior=""??)

I agree we should have a section on the behavior attribute, but if we use actual elements like you mentioned in #702 and #703 then the behavior attribute would go away so I'll hold off for a little bit

ways of modifying the behavior of existing content attributes (slot="")

I don't see how we are modifying the existing behavior of the slot attribute

[domenic]

Right now slot="" is used for assigning to web developer defined slots. Redefining it to slot into some sort of user agent internal slot is a behavior change. (E.g. it changes how a selectmenu inside a shadow tree with its own slots would behave.)

[gregwhitworth]

New special content attributes (behavior=""??)

Yep, I think this is a key thing that we need to land ASAP. We do not intend on introducing new HTML elements for all parts of components/controls that we recommend introducing unless they make sense on their own. So the key thing we need specified here is the behavior content attribute and how this wires up the functionality.

@josepharhar note that some of this content is in our very early draft for customizable controls here although we moved away from using the part attribute (I'll need to track down the issue for why we needed a new one and couldn't overload it for use in HTML).

Right now slot="" is used for assigning to web developer defined slots. Redefining it to slot into some sort of user agent internal slot is a behavior change. (E.g. it changes how a selectmenu inside a shadow tree with its own slots would behave.)

Then this is correct in that we are recommending a behavior change, thanks for calling it out.

[domenic]

We do not intend on introducing new HTML elements for all parts of components/controls that we recommend introducing unless they make sense on their own.

My point is precisely that this intention of yours is counter to the design of HTML so far, and so I recommend against it, if you want to land on something that will fit with browser implementations and the HTML Standard.

[gregwhitworth]

My point is precisely that this intention of yours is counter to the design of HTML so far, and so I recommend against it, if you want to land on something that will fit with browser implementations and the HTML Standard.

This becomes priority number one for us to solve then because this is a key pillar to enable extensibility of the controls/components being defined while allowing them to not have to duplicate all of the functional capabilities.

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[josepharhar]

I think that the current state of the explainer answers all of these questions. I replaced the behavior attribute with new elements and listed them all out.

I suppose that <listbox> could be defined in more detail, but I currently have my own explainer for that for now: https://github.com/josepharhar/explainers/blob/main/listbox.md

[lukewarlow]

@josepharhar is it worth copying that across to an openui mdx file? Just so it can get updated to latest things and be referenced during discussions? (e.g. it says :selected but we decided to stick with :checked for now, and the content model section seems to contradict how it works in selectlist)

[josepharhar]

is it worth copying that across to an openui mdx file

Yes! lets talk about it here: #896