The fact that I'm disproportionally excited about this probably dates me as an early 2000s web developer. But since selects can do things that you simply cannot recreate in HTML, e.g. have options drop downs that extend outside the viewport boundaries, makes this a really helpful feature.
The challenge till this is widely supported (caniuse.com currently pegs it at 46% globally [1]) will be using this as a progressive enhancement that does not provide a worse or unusable experience for users with browsers not supporting it yet.
In other words, don’t include critical information or functionality in the new styling that isn’t available in the underlying plain select element! But such is always a good practice anyway.
Very nice to see this taking shape though! Should be a huge improvement over the div monster that custom select box replacements often are. :)
> It doesn't trigger built-in mobile operating system components.
I worry about this. The built-in mobile operating system components are reliable, accessible, and responsive. I really like it when an input element opens the Android UI because I know how it works and that it is reliable. This applies to <select>, but also date/time inputs for example.
Some controls are better left unstyled. Look what happened to scrollbars: either they are too thin to grab, have bad color contrast, so it is hard to see what part to actually grab, and, finally, some smartypants have managed even to remove scrollbars altogether from their website. Sure, default select is not the prettiest control, but it gets it job done.
This looks like what web developers have been waiting literally decades for. Possibly replacing (eventually) a bunch of JS libraries to make this all do what we want.
I don't have Chrome installed, but I'm curious how it handles multi-select fields, as I didn't see that in the example video.
Better than broken JS libs but my main concern is the layouting yank, when there are many options and how to reach them without accidentally closing the select.
> It doesn't trigger built-in mobile operating system components.
Yeah so this is scary, but how is layouting done then?
> Shown options positioned with anchor().
Ok, also experimental, but maybe this is the best part of all? Floating UI? It’s become a reusable thing with JS, it would be amazing if it was in CSS and actually worked.
Fascinating timing for this feature. I suspect the AI chatbot explosion has been a major driver behind the push for richer select elements.
Have you noticed how every AI interface needs to let you choose between models? The current select element is embarrassingly inadequate when you need to show more than just text labels. You want to display model capabilities, performance indicators, context sizes - not just "GPT-4" vs "Claude 3.7" as plain text.
I still wish it would grow some primitive filtering/searching feature. I'm very tired of having to reach for JavaScript just to let users narrow a massive list of things
What I was recently disappointed to find out is that you can't have a separate "display name" for the option items. That is, when the user clicks and the dropdown opens, I want the item labels in the dropdown to be of the form "$TITLE ($SHORT_DESCRIPTION)", but then when the dropdown is closed and something is selected, the control should just read "$TITLE". There are a few hacks to sort of make that work, but they all have downsides that make them unusable for me. (The purpose for me was to make it so the <select> element doesn't take up as much horizontal space; most of the workarounds end up missing that quality.)
There was one thing that I hoped would work, but didn't, which is applying an :after pseudo-class to <option>, so something like this:
Unfortunately this just doesn't work (I presume because <option> can't contain DOM elements aside from unstyled text), but I wonder if it will work now.
meh. it looks really nice but I would rather do the basic styling I can do now for the 99% of the times where I don't really need it.
I have said it before, everyone (Developers that use Chrome almost exclusively) says Safari is the new IE but Chrome has been slowing becoming the thing they fought against since they defeated IE.
This web API scope creep makes it __harder__ to create and maintain truly independent web browsers.. you have to implement more and more and eventually we arrive at the current state of matters - all non-chromium engines are lagging behind.
Developers will happily use this, then users will notice websites "look better" in chrome and firefox will become even less relevant. Don't.. you can already achieve this without relying on chromium-only APIs.
The <select> element can now be customized with CSS
(developer.chrome.com)499 points by tosh 31 March 2025 | 185 comments
Comments
Now, do autocompletes and tag selectors next...
In other words, don’t include critical information or functionality in the new styling that isn’t available in the underlying plain select element! But such is always a good practice anyway.
Very nice to see this taking shape though! Should be a huge improvement over the div monster that custom select box replacements often are. :)
[1] https://caniuse.com/mdn-css_properties_appearance_base-selec...
I worry about this. The built-in mobile operating system components are reliable, accessible, and responsive. I really like it when an input element opens the Android UI because I know how it works and that it is reliable. This applies to <select>, but also date/time inputs for example.
I don't have Chrome installed, but I'm curious how it handles multi-select fields, as I didn't see that in the example video.
https://developer.chrome.com/blog/a-customizable-select
> It doesn't trigger built-in mobile operating system components.
Yeah so this is scary, but how is layouting done then?
> Shown options positioned with anchor().
Ok, also experimental, but maybe this is the best part of all? Floating UI? It’s become a reusable thing with JS, it would be amazing if it was in CSS and actually worked.
Have you noticed how every AI interface needs to let you choose between models? The current select element is embarrassingly inadequate when you need to show more than just text labels. You want to display model capabilities, performance indicators, context sizes - not just "GPT-4" vs "Claude 3.7" as plain text.
https://imgur.com/7gfXRrm
There was one thing that I hoped would work, but didn't, which is applying an :after pseudo-class to <option>, so something like this:
Unfortunately this just doesn't work (I presume because <option> can't contain DOM elements aside from unstyled text), but I wonder if it will work now.Sounds like you can create loops. If the select had a style element that turns this off again would it keep changing state?
I have said it before, everyone (Developers that use Chrome almost exclusively) says Safari is the new IE but Chrome has been slowing becoming the thing they fought against since they defeated IE.
Since then my faith in Web technologies for building UI for most apps keeps increasing.
Through pure evolution - it's the most beautiful and open platform that's most cross platform.
This web API scope creep makes it __harder__ to create and maintain truly independent web browsers.. you have to implement more and more and eventually we arrive at the current state of matters - all non-chromium engines are lagging behind.
Developers will happily use this, then users will notice websites "look better" in chrome and firefox will become even less relevant. Don't.. you can already achieve this without relying on chromium-only APIs.