The <select> element can now be customized with CSS
183 comments
·March 31, 2025wolframhempel
asddubs
I doubt it'll still be able to do those things. From the article:
>Using base-select loses a number of features and behaviors:
> The <select> doesn't render outside the browser pane.
> It doesn't trigger built-in mobile operating system components.
I have mixed feelings about it. Mobile users, get ready for poorly optimized select elements. On the other hand it reduces the need for javascript for styling forms, which is good
cush
> The <select> doesn't render outside the browser pane. ... It doesn't trigger built-in mobile operating system components.
To me, this is intrinsically what makes a <select> a <select>. Styling is great, but without these features, this doesn't really bring anything new to the table
wruza
With these features scammers will create all sorts of "you have to log into your password manager" popups again.
tadfisher
Thanks to humanity, supporting this is a surefire ticket to someone figuring out how to phish credentials through a <select> element.
kmeisthax
For the record, there's already a bunch of custom select-a-like replacement elements out there; I'm partial to select2. The main reason for this is that selects don't come with what we used to call "combobox" features; there's no type-ahead completion, and you can't lazy-load options from a larger data source because of that.
My main gripe is the loss of rendering outside the browser pane. To be clear, we already don't have that on mobile at all; if you've ever used an iPad with Stage Manager you'll note how popovers - all of them, including native apps - are neatly conformed to the bounds of the containing window. Pop-over menus are supposed to break the window pane, but they don't, for reasons I don't quite understand but can guess rhyme with the word "security".
Eric_WVGG
"It doesn't trigger built-in mobile operating system components." Is that part of the spec? I can see Apple deviating from that implementation.
jraph
I'm not sure about this. It could break the positioning / sizing / box CSS properties.
That would require rendering arbitrary HTML in the native widget, outside the browser. And I think that would require putting WebKit in the native widget. Or, to maintain a "copy" of the widget that looks like the native one but uses WebKit to render things. Seems annoying to maintain.
(And there are the security concerns mentioned by the other comments)
wolframhempel
That's fair, but I assume that is the initial implementation. Surely, over time, browser vendors will want to make the full spectrum of select functionality available consistently.
caesil
I don't think browsers will ever let web code affect things outside the viewport because scammers would cook up some truly zany things with that power.
dbbk
Definitely not. Why would they let web devs render outside of the browser window? That's a recipe for disaster.
immibis
Mobile users are the majority of users by far. Do web designers really make their sites hostile to most of their users? (I suspect the answer is yes)
qiqitori
I think this totally depends on the site in question. Seriously researching something is hell on mobile browsers. As is doing productive stuff. Who wants to work on a tiny screen and no keyboard? On the desktop you can open dozens or hundreds of tabs on a single topic. Therefore I'm not surprised to see that on my site (technical articles) I can see the number of requests from mobile devices is just 17%.
Windows is 52%, Linux (without Android) is 18%, Macintosh is 13%, Android 11%, iOS 6%, Chrome OS 0.5%, others <0.5%. (Android and iOS may include tablets, but the overall traffic from tablets is just a few percent.) (Note that I've excluded crawlers and unknown user agents (bots and crawlers) from these results.)
FWIW, some bots lie about what they are, which typically inflates the Windows results. I have another source of data, I can see what types of devices saw my site in Google results, and it's 69% desktops, 30% mobile, 1% tablets. (I can also see how many clicked, and it's similar numbers.)
majora2007
It's actually crazy that we don't have a basic typeahead component or tag selector in this day and age with HTML. Every web page I've ever built has needed these components and while there are libraries out there, they all have an annoying bug here or there.
But considering we are just now getting Select tags with styling, signals how long it might take for a typeahead which is vastly more complex.
cosmic_cheese
Why implement broadly useful HTML widgets when you can instead put those engineering resources to work on a new WebBeer API that fetches the number of beers in the user’s fridge or something else similarly niche?
asddubs
also drag and drop rearrange
kkarpkkarp
> Now, do autocompletes
This is kind of ready, see datalist element.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...
porridgeraisin
I know about datalist, but it's the saddest autocomplete experience you can offer. If something is not fully styleable, it's automatically garbage. If it's styleable, it may be decent.
Now, I understand why datalist is not styleable the way it is implemented right now. On Android, the suggestions come on the top bar of the native keyboard, so it doesn't make sense to be able to put arbitrary divs there. But in that case, there should be an alternative styleable autocomplete element.
Another element that is unstyleable crap is <input type=file>, <audio> too.
renerick
> have options drop downs that extend outside the viewport boundaries
Unless this is about something different from what you mean, unfortunately, it's not the case, as stated in the article:
> Using base-select loses a number of features and behaviors:
> The <select> doesn't render outside the browser pane.
preisschild
<input type="datetime-local"> with automatic ISO8601 timezone offsets would be awesome too!
sublinear
ISO-8601 is not the correct format for serializing local time unless it's in the past.
In my experience, a local datetime picker is going to be used almost exclusively for a future date and time. What you want instead of a timezone offset is a zone ID. That way date and tzdata can handle it properly on the backend.
progmetaldev
For this case, I will often ask for the timezone, since that data is often updated on the operating system, but I don't believe it's often for someone to be in the same location and have their timezone change. The software that I've maintained the most over the years (since 2009 up to deploying an update today) requires a login, so I have a client account that includes choosing their timezone. I then use that to convert everything to UTC in the database, and when I retrieve the data, I use it to convert UTC back to their local date/time. I felt that it was the best option, since a user moving to a different timezone should still be able to get dates/times back relative to where they have their current timezone set.
ibejoeb
Right. The offset is not enough without a reference recorded time. You need the time and the time zone in order know the true time. This is a big problem is systems that don't have an intrinsic time type that deploy and have a database full of ambiguous times. Once it happens, backfilling that is a real slog.
blatantly
Ooh I can render arbitrary pixels outside the viewpoint. Like a system dialog asking for a password.
ljoshua
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. :)
[1] https://caniuse.com/mdn-css_properties_appearance_base-selec...
ddoolin
I agree that this is a huge improvement, but it's also over a decade late IMO. This should've been accomplished well before now, especially given that the issue has been there since the beginning.
pclmulqdq
Because frontend is frontend, Javascript frameworks dominated the conversation even for silly things like basic web forms for the past 15 years. Basic HTML/CSS is now catching up to the fact that not everyone wants to run a Javascript monstrosity for custom styling on very basic tasks.
no_wizard
The prevalence of JS and JS backed components is due to the reluctance of browser vendors to introduce new HTML elements that everyone has been lobbying for in the same time period.
By and large browser vendors for the longest time, even today still in many respects, repeatedly ignore pleas for more elements that cover common use cases.
Even when they do arrive, they can be half baked - like dialog or details / summary - and that doesn’t help matters
hombre_fatal
Forms are hard because they are the most stateful and most ubiquitous UI component that everyone comes in contact with. HTML has a few barebones tools to help you out, but they aren't good enough for the best user experience if you really wanted to polish a form like show errors exactly when you want to show them and only allow submission exactly when you want to allow it and represent error states in much better ways.
It's especially obvious once you're making forms outside of HTML and you realize that it's not any simpler with any less UX consideration. The only thing that changed was the language you're writing that polish in.
null
ksec
Over TWO decades late.
It is crazy to think what we only just have in anything non JavaScript in the past 20 years.
Cthulhu_
It's like how border-radius was added after rounded corners via images fell out of fashion.
true_religion
I somehow feel Safari drags its feet on basic things platform improvements because they want to focus on iOS apps instead.
alwillis
The narrative Safari is behind and Apple doesn’t care about the web is so tired…
This 8,000+ word article on Safari 18.4 (released today, BTW) doesn’t read like an organization that doesn’t care about the web [1].
[1]: https://webkit.org/blog/16574/webkit-features-in-safari-18-4...
arp242
Eh; the standard is two weeks old. Written by someone working for Apple by the way.
paddy_m
This is true, and I try not to get eager about new browser improvements for this reason. But look at the porgress over time in browser abilities, it's astounding.
The days are long but the years are short.
klysm
This might be a bad take, but I think developers should also consider exactly which users are using their app. If it’s the entire internet, then absolutely you need to consider backwards compatibility. If it’s an internal app, then consider not caring and using new APIs.
no_wizard
The perpetual 5 year problem of web development. I wish there was a way to do forward standards
bsimpson
> But such is always a good practice anyway.
One more reminder to develop for people who may not perceive color and shape as you do. If you're hiding critical information in your menu styles, that information is presumably inaccessible to people who are using a screen reader.
simiones
You'll probably still keep a <div>-based control in your page, and selectively hide the <select> based one or this one, or generate different HTML for different browsers if you can do that.
nasso_dev
> 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.
dimal
This is only if you opt in to base-select, so if you don't use that, everything should continue to work the same, as far as I can tell.
Macha
"You" in this case is the website author. From a user perspective, that doesn't solve the problem.
gruez
Chrome already uses plenty of non-native components. Firefox is similar. Moreover while I can understand the concern about poorly implemented components from random web developers, Google is probably the best positioned to implement a widget that faithfully replicates the native equivalent, at least on Android.
johannes1234321
> Chrome already uses plenty of non-native components. Firefox is similar.
This is then won't be consistent with native OS apps, but still be consistent across websites. Better than everybody doing different div+JavaScript magic which behaves slightly different across different websites.
asddubs
you're misunderstanding, this will leave the appearance of the select on mobile up to the web developer
butz
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.
dimal
This ship sailed in 2000. We've been hacking custom select boxes since then, so we may as well pave the cowpath. And besides, as a user, I want stylable select elements. Seeing an ugly old select box in the middle of a site where everything is styled consistently is jarring.
And it doesn't get the job done. You can't put stuff like SVGs or complex DOM elements in them, which is a valid use case. Most of the time, when people create custom select boxes, they ignore accessibility. This will fix that issue.
crazygringo
This is more about rich HTML for the select options. Being able to select images, rows with two columns of information, extra information in a contrasting font weight, etc. This will be extremely helpful.
SoftTalker
Unlikely. Things need to be simple and consistent. The web is already a disaster on both of those factors and has been for a long time.
crazygringo
No, things need to communicate the required information for the task at hand.
Limiting information can be harmful in many cases, and make things more difficult rather than simpler. And consistency can similarly limit usability.
What if I want to select one of 10 colors, with limited screen space? Isn't a select with color swatches perfect? Or even better, color swatches with color names beside? Why do you think that should be limited to plaintext only? That's anti-user.
userbinator
managed even to remove scrollbars altogether from their website
What's worse are the custom JS ones that only appear on hover, obscuring the contents partially where they happen to be, and then when you try to drag them and accidentally move the pointer just a tiny bit off their skinny width, they disappear and you end up accidentally activating whatever element happens to be underneath.
streptomycin
Unfortunately those unusably small or invisible scrollbars are the default in many browsers. Such as Firefox on Linux, which I'm using right now.
lblume
I think this really comes down to personal preference. I also use Firefox on Linux and always find the Windows-type scrollbar to be incredibly ugly and bulky, especially on other overflow: scroll elements.
BrenBarn
Exactly. It's personal preference, which means it should be the user's choice, not the site designer's.
layer8
Luckily Firefox allows changing that default.
65
I disagree. On my website I have a sidebar and a main content area. You are able to scroll through posts on the sidebar and through the content on the main content area. The sidebar is a dark color. Being able to use a thin sidebar and make the color of the sidebar dark to match the background makes the website look a lot better than having a clunky white sidebar on a dark background.
The user can still obviously see the sidebar and knows its a sidebar, it just works better with the design.
KTibow
Ideally web browsers would use better defaults so you wouldn't have to do this. Firefox is good with this in my opinion: scrollbars are very subtle, don't affect content width, and adapt to the `color-scheme`.
montag
I may not agree with your ugly scrollbars, but I will defend your right to style them.
(If you want to annoy your users, that's your prerogative)
dpcx
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.
dqv
I just tried it in the Codepen and it reverts to a regular old UI element when it has the multiple attribute.
Also just tried it with multiple="multiple" just in case. Same behavior.
no_wizard
Huge miss in my opinion. If it doesn’t support all scenarios I’m not sure what the Chrome team is thinking here
kelnos
I expect they're thinking they should ship something that works, and covers some use cases, and gradually improve it over time to support more use cases.
Y'know, like how most software development works.
dqv
I was just wondering how people do a custom <select multiple> now. I guess they make it screen-reader-only and then have aria-hidden checkboxes for everyone else.
pests
Incremental improvement?
Why release anything right?
zachrip
That really sucks :/
Contax
> This looks like what web developers have been waiting literally decades for.
Count me in. Most times it didn't matter to me but there were some cases when I wanted or needed them to have a specific style matching other elements and, yes, I could only do it -to the best I knew- with JS.
Let's see if it becomes widely supported.
chias
The <select> element can now be customized with CSS *in Chromium browsers*
robin_reala
It’s the web equivalent of the Twitter account that added “in mice” to medical headlines. Nice in theory, but it’ll take years before it’s usable and in all likelihood it’s just another experiment that’ll never go anywhere.
silverwind
So at least 5 more years until in can actually be used.
spartanatreyu
Firefox already has indicated that they approve of the new proposal: https://github.com/mozilla/standards-positions/issues/1060
We're only waiting on Safari now: https://github.com/WebKit/standards-positions/issues/386
pier25
At least...
indie_architect
Can't wait to use it in 2030 when my work stops supporting IE11
olyjohn
Don't worry, they'll get extended support. Again.
ruined
firefox issue https://bugzilla.mozilla.org/show_bug.cgi?id=1944403
everybodyknows
> priority: Not set
Last update to the issue is a pointer to test results:
https://wpt.fyi/results/html/semantics/forms/the-select-elem...
At least Safari is failing as well, currently, so the FF team has a bit of time.
rsingel
Oh the irony of the Chrome dev blog failing Google's own Core Web Vitals test
tracker1
Damn... been wanting this for well over two decades. About time. Still missing a good combo-box and type-ahead solution from the box.
earcar
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.
codedokode
Making web standards even more complicated one change at a time.
klabb3
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.
pests
>> It doesn't trigger built-in mobile operating system components.
>Yeah so this is scary, but how is layouting done then?
Via HTML in-website, not via opening the android wheel picker or anything like that.
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.
Now, do autocompletes and tag selectors next...