[select] removing pseudo element for fallback button

[josepharhar]

I got feeback from apple that we should remove ::select-fallback-button

https://github.com/w3c/csswg-drafts/issues/10717

I don't think we will limit any use cases by doing this, and I think it will be better because it shouldn't limit any use cases. What do yall think?

[josepharhar]

Not sure where the minutes went, but we resolved at the meeting today to remove the pseudo-element and the fallback button element

[css-meeting-bot]

The Open UI Community Group just discussed [select] removing pseudo element for fallback button, and agreed to the following:

• RESOLVED: remove ::select-fallback-button and the fallback UA button element in the UA shadowroot of select

The full IRC log of that discussion

<dbaron> ScribeNick: Penny
<Penny> jarhar: the select element for customizable select has a button element inside of it, which is the thing you click to interact to open the popover and is the thing that can be replaced with an author button with this whole slotting mechanism. Feedback from apple is that the way that authors currently apply CSS properties to the button part of the select is by putting those properties on the element itself. Discussed architectural ideas to remove
<Penny> the pseudo element. It was complicated. Mason and Una reported that properties applied to the select element weren't mapped to the fallback button.
<masonf> q?
<Penny> This is similar to what Tim was saying in the Apple feedback
<masonf> q+
<Penny> jarhar: Would prefer not have any magic UA rendering, allow the author to do anything they want to it
<Penny> jarhar: the proposal is to remove the fallback button from the UA shadow root and remove the pseudo element to target it
<Penny> masonf: sounds like there are no downsides, is that right?
<keithamus> q+
<masonf> ack mason
<Penny> masonf: the easier and more straightforwad thing is to just put the styles you want on the select itself. Are we losing anything by just removing the button?
<sanketj_> q+
<Penny> jarhar: I don't think so. But if anyone else can think of anything we should hear it
<masonf> ack keith
<Penny> keithamus: am i understanding correctly that you would like the detail summary element because teh select has an amount of children right now which are options? How would one express interleaving the content and selected option while also expressing the avaialable option tags within the menu?
<Penny> masonf: this is just the removal of the fallback button in the like Dom. You can still do emoji, selected option, emoji whatever you want to put in that button.
<Penny> jarhar: that's correct, if you want to provide your own button and put stuff in it that's supported
<Penny> jarhar: what makes it hard to implement, is when the author provides their own button, all that extra comes from the outer select element and will be removed using. The outer border of the select will go away when you provide your button.
<Penny> masonf: that's new to me to, if you provide your own button I was thinking you just do a select border:0
<masonf> q?
<masonf> ack sanket
<Penny> jarhar: If they provide a button and it's in base then render the button. Don't render the borders around the regular select element. There's never a case where there's two sets of borders by default.
<Penny> sanketj_: for the split button use case what would change for authors to enable that?
<Penny> jarhar: this does not impse changes to split buttons
<Penny> jarhar: the current way is to have the table which lives outside the select then create a separate button somewhere else and position your select adjacent to that one
<Penny> masonf: that is still being discussed separately and not clear it's a v1 feature
<Penny> sanketj_: it's interesting that if the selected option and you ahve a bvutton that appears to be part of that control but is actually outside.
<masonf> q?
<Penny> masonf: you can only put one button that matters inside the select
<Penny> masonf: paraphrasing, not hearing any objections, is that the proposed resolution ?
<Penny> jarhar: yes it is
<Penny> jarhar: if anyone encounters any problems, please let me know, doesn't have to be a permanent decision
<Penny> scott: if someone wanted to style uncustomized selects vs customized selects, would they have to do a has: button inside of it?
<Penny> scott: we did resolvve that uncustomized selects have a different keyboard navigation behavior than customizable selects
<Penny> jarhar: plan is that when appearnce: base is on it you get new keyboard behavior
<Penny> jarhar: if the author provides a button then we throw it away because this is appearance:auto
<Penny> masonf: the answer to scott's question would be to do a styhle query for the value of the appearance property
<Penny> una: when you're in appearance: base mode you're already in a new customizable select mode
<Penny> scott: my question is if someone uses the selector and apply a style to it. But how can I apply a style to uncustomized selects vs customized select, what would selectors be for that?
<Penny> scott: someone could have a customizable select that they've put onto their page, you know are using a third party component that has an old school select in it
<Penny> una: @supports would be the way to go there
<Penny> keith: you could use a container query with a style query
<Penny> una: that would be the way to do it
<Penny> masonf: is that supported?
<Penny> una: is property value pairs supported? You'd have to add a custom property to your appearnace-based select and then add a custom property
<Penny> masonf: does that step around scott's question? His question is if there is a 3p stylesheet that sets appearance:auto
<Penny> masonf: there shouldn't be something special for select for this
<Penny> una: one reason we didn't implement property pairs for style queries was lack of use cases, it's already specced
<Penny> scott: fine with whatever answer as long as this can be done
<masonf> q?
<jarhar> q+
<Penny> scott: the fact that keyword behavior with select is different you know when this is going to be a new element that made a lot of sense. Because CSS keyboard behavior no longer works as expected any more. There's going to be very little in the actual way of differences. Even tho I like the new behavior it shouldn't be something that is styled differently now. There should be a conversation about whether select should just behave this new way.
<Penny> una: never said I like the idea that it all became one element
<masonf> ack jarhar
<Penny> jarhar: I backed off after feedback from Anne that they would not be amenable to having our keyboard behavior because they want it to follow platform conventions. But happy to file a new issue on this.
<una> s/una/scott
<Penny> scott: if anything keyboard behavior is getting closer to webkit
<masonf> q?
<jarhar> proposed resolution: remove ::select-fallback-button and the fallback UA button element in the UA shadowroot of select
<masonf> +1
<brecht_dr> +1
<keithamus> +1
<jarhar> RESOLVED: remove ::select-fallback-button and the fallback UA button element in the UA shadowroot of select
<jarhar> zakim