material-ui
material-ui copied to clipboard
mui
[select] Rely on native stylable select
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
https://github.com/whatwg/html/issues/9799
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).
@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.
Sure, I'm happy to revisit this in two years. For now, a Base UI version is a must.