So after decades of developer pain, all we're getting is a better select?
Where is the native HTML datagrid (that supports sorting, filtering, paging, downloading, row/column freezing, column resizing and re-ordering)?
Where are the native HTML Tabs control? Image selector, resizer/cropper, and uploader? Toggle button? etc.
We can't even get text input to respect autocomplete directives properly. On the major browsers, giving your user id and password inputs nonsensical names seems to be required, along with numerous other hacks, to ensure that when a user is registering, the form is not auto-completed with saved passwords.
I've been doing front-end since the days of IE5 and I'd be rich if I had a penny for every time I've had to do a custom "select". It's a pain to use third-party libraries for this, but it _is_ a solved problem and doesn't require that much extra code.
I spent days building this little perfect dropdown select thing, that is a hundreds lines of code and even more docs explaining what the hell is going on. Someone wasted the same amount of time before me. Someone else spent a lot of time before them. And so on.
I wish we have had more browser native implementations including some notion of virtual lists so the browser would not choke when rendering a lot of content.
---
Eventually, this would be same as border-radius. It will get implemented and we'll forget about that forever.
- Why is picker a function like `::picker(select)`, and not a CSS pseudo class like `::before` to select the `select`'s `picker` component? I.e., `select::picker` makes a lot more sense to me.
- What about multi-choice (`multiple` attribute) `select`s?
In fact, I remember at some point, they were trying to sell the idea of exposing all the form inputs to use the `::part` API, since under the hood form inputs share the same general logic of custom elements, If I recall correctly.
From the looks of it, didn't work out that way though.
And I think its for the best. I like this proposal more, even though delivering the `::part` API to everyone (not just web component users) would have likely been faster
This is a very good start, I don't think it'll replace a lot of the custom code/comboboxes that are seen in react-land without search (unless I missed it).
I worry this will lead to a bad user experience if android et al does not support it natively.
You'll have people saying "select the green option in the drop-down list to do <foo>" and people on mobile will just get the native-ui list with no styling.
i've re-implemented select in worse and less-accessible ways many times to satisfy some business demand. i'm very excited if this means i don't have to keep doing that.
I'm hoping that the documentation around this will be good, I've recently tried out CSS anchor positioning and it's riddled with examples that no longer work as the specification has been changed various times
Customizable HTML Select
(developer.chrome.com)218 points by dsego 20 February 2025 | 137 comments
Comments
Where is the native HTML datagrid (that supports sorting, filtering, paging, downloading, row/column freezing, column resizing and re-ordering)?
Where are the native HTML Tabs control? Image selector, resizer/cropper, and uploader? Toggle button? etc.
We can't even get text input to respect autocomplete directives properly. On the major browsers, giving your user id and password inputs nonsensical names seems to be required, along with numerous other hacks, to ensure that when a user is registering, the form is not auto-completed with saved passwords.
HTML is really holding us back right now.
(And yes, I'm still bitter about you all wrecking my scroll bars.)
I wish we have had more browser native implementations including some notion of virtual lists so the browser would not choke when rendering a lot of content.
---
Eventually, this would be same as border-radius. It will get implemented and we'll forget about that forever.
- What about multi-choice (`multiple` attribute) `select`s?
And what about the nearly unusable (on desktop) <select multiple>?
In fact, I remember at some point, they were trying to sell the idea of exposing all the form inputs to use the `::part` API, since under the hood form inputs share the same general logic of custom elements, If I recall correctly.
From the looks of it, didn't work out that way though.
And I think its for the best. I like this proposal more, even though delivering the `::part` API to everyone (not just web component users) would have likely been faster
You'll have people saying "select the green option in the drop-down list to do <foo>" and people on mobile will just get the native-ui list with no styling.
i've re-implemented select in worse and less-accessible ways many times to satisfy some business demand. i'm very excited if this means i don't have to keep doing that.
edit: this is a joke about "OpenGL Core Profile with the WebGL renderer" which I'm not sure if Chrome (browser) would be responsible for