[select] Rely on stylable select

[oliviertassinari]

Summary

We support two select modes:

• "normal" https://mui.com/material-ui/react-select/#basic-select
• "native" https://mui.com/material-ui/react-select/#native-select

The native select mode is meant to improve the UX on mobile, it's also meant to improve the performance when hitting limits with the "normal" one.

With the introduction of https://developer.chrome.com/blog/new-in-web-ui-io-2024#stylable_select, I wonder:

• Should we adopt this feature for our native select, matching the style of the none native one?
• Do we even need a Base UI select component. A question for Select component owner and maintainers to answer https://www.notion.so/mui-org/Select-31a61434055c498abf0f4a47254242e8

Motivation

whatwg/html#9799

[michaldudak]

Should we adopt this feature for our native select, matching the style of the none native one?
Do we even need a Base UI select component

Citing the article you linked: "The bad news is that this API is still very much in an experimental state at this time"

So yes, we need the component in Base UI. Plus, we offer a bit more functionality (like options' values being rich objects).

[oliviertassinari]

@michaldudak I agree if we take today's lense.

Now, if we look two years in the future, and this API is widely available, I wonder. In any cases, the objective with this issue is to gather user demand, we will see how browsers make progress on this.

If it's not abandoned by the platform, and we keep a non-native select, it feels like we will need to style the native select like our non-native one. Developers targeting mobile seem very likely to not want the non-native select (I fail to envision why they would want it), and they might be too lazy to toggle the non-native one desktop.

like options' values being rich objects

This is nice, I imagine this could be implemented too with a native select wrapper though.

[michaldudak]

Sure, I'm happy to revisit this in two years. For now, a Base UI version is a must.