Open oliviertassinari opened 3 months ago
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.
Summary
We support two select modes:
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:
Motivation
https://github.com/whatwg/html/issues/9799