alt.hn

3/31/2025 at 9:11:47 AM

The <select> element can now be customized with CSS

 https://developer.chrome.com/blog/a-customizable-select

by tosh

3/31/2025 at 3:14:52 PM

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...

by wolframhempel

3/31/2025 at 3:22:48 PM

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

by asddubs

3/31/2025 at 6:17:24 PM

> 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

by cush

4/1/2025 at 5:48:44 AM

With these features scammers will create all sorts of "you have to log into your password manager" popups again.

by wruza

3/31/2025 at 10:37:17 PM

Thanks to humanity, supporting this is a surefire ticket to someone figuring out how to phish credentials through a <select> element.

by tadfisher

4/2/2025 at 4:24:36 PM

Certainly, there exists a middle ground between having no options for styling and some options where we don't compromise users

by cush

3/31/2025 at 9:01:06 PM

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".

by kmeisthax

3/31/2025 at 4:44:45 PM

"It doesn't trigger built-in mobile operating system components." Is that part of the spec? I can see Apple deviating from that implementation.

by Eric_WVGG

3/31/2025 at 6:57:27 PM

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)

by jraph

4/1/2025 at 12:44:37 AM

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)

by immibis

4/1/2025 at 3:53:28 AM

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.)

by qiqitori

3/31/2025 at 3:28:43 PM

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.

by wolframhempel

3/31/2025 at 3:46:06 PM

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.

by caesil

4/1/2025 at 12:46:40 AM

Even rendering arbitrary pixels inside the viewport is bad enough. Something that went out of fashion but is apparently now back in fashion is detecting the user's operating system and browser, then displaying a pixel-perfect replica of a second browser window open to Paypal and asking you to log in... displayed within the bounds of the first browser window.

by immibis

4/3/2025 at 6:29:29 PM

This is why the new login prompt of 1Password is worse than the old one, it appears at the center of the screen where the website could easily put a replica. The old one opened at the height of the extension icon, a bit above where the browser opens the alert dialog

by afiori

3/31/2025 at 3:54:19 PM

Definitely not. Why would they let web devs render outside of the browser window? That's a recipe for disaster.

by dbbk

3/31/2025 at 6:25:47 PM

There needs to be some middle ground. I'd trade off just being able to set just the background color and font and keep these native-like features

by cush

4/3/2025 at 6:24:53 PM

I think that you can compose arbitrary images that way using an image-like font (using various Unicode chars and assigning to each a small tile of the full image)

Actually I am now curious of how much detail/size/colours/animations you can fit in a single letter.

by afiori

4/1/2025 at 1:55:52 AM

The following works for me in Chrome, and doesn't prevent the menu from going outside of the viewport:

    select, option {
        background: red;
        font-family: 'comic sans ms';
    }

by eurleif

4/1/2025 at 3:32:40 PM

Yeah, it only works in Chrome

by cush

3/31/2025 at 10:21:32 PM

If that's all your changing, then why can't you make do with the system default?

by maccard

3/31/2025 at 3:17:08 PM

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.

by majora2007

3/31/2025 at 11:49:13 PM

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?

by cosmic_cheese

3/31/2025 at 3:18:40 PM

> basic typeahead

It isn’t perfect, but have you tried <datalist>?

Totally agree about tag pickers, I was bummed to see that Bootstrap didn’t have a tag selector component either.

by jhardy54

3/31/2025 at 3:47:14 PM

I have, and failed.

See https://news.ycombinator.com/item?id=40265782

by mlhpdx

3/31/2025 at 6:27:26 PM

It may not be present in Apple’s official documentation but it has been supported since Safari 12.2.

See https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da... compatibility. The demo on that page works for me in current Safari on both iOS and Mac.

by ricenews

4/1/2025 at 2:31:54 AM

Some examples seem to work better than others though. I’m on latest iOS and sometimes it will invoke the native date picker like you’d expect to see, sometimes it won’t, and the type ahead doesn’t seem to work consistently

by no_wizard

4/2/2025 at 7:14:53 PM

That demo shows the problems splendidly. It “only kinda” works on iOS.

by mlhpdx

3/31/2025 at 5:32:49 PM

Safari is the "new" IE. I put "new" in quotes because it's been this way for like a decade.

by recursive

3/31/2025 at 7:56:20 PM

--- start quote ---

Back fifteen years ago IE held back the web because web developers had to cater to its outdated technology stack. “Best viewed with IE” and all that. But do you ever see a “Best viewed with Safari” notice? No, you don’t. Another browser takes that special place in web developers’ hearts and minds.

--- end quote ---

https://www.quirksmode.org/blog/archives/2021/08/breaking_th...

by troupo

3/31/2025 at 9:01:30 PM

Yes, Safari is not exactly like IE because IE had a dominant user share once upon a time.

We don't see "best viewed in Safari", but we do see plenty of sites that can be viewed in Safari, despite the extra effort used to get them there. And I'm not even a regular chrome user.

by recursive

4/1/2025 at 8:23:51 PM

The absolute vast majority of web sites require no effort to "get there".

The absolute vast majority of those which don't work in Safari use Chrome-only non-standards.

And there is a tiny minority of sites that run into some Safari-specific quirks

by troupo

3/31/2025 at 7:53:32 PM

If anything chrome is the engine with odd quirks you are forced to work around.

by facile3232

3/31/2025 at 9:02:33 PM

I haven't found this to be the case in my experience.

by recursive

3/31/2025 at 9:03:57 PM

Maybe it's just iframes that are the issue but they were a devil and a half to get working in chrome (or blink ig) without relying on third party cookies.

by facile3232

3/31/2025 at 10:47:44 PM

Interested in what you are doing with the iframes. Something with complex authentication? I've been forced to use iframes a few times for 3rd party resources that should have been first-party (mostly with banks and credit unions), and have only had some styling issues on mobile (which have been overcome by using JavaScript and window.matchMedia to check for media queries).

by progmetaldev

4/1/2025 at 12:47:29 AM

Chrome's quirks become the standard and other browsers have to implement them.

by immibis

3/31/2025 at 3:23:46 PM

also drag and drop rearrange

by asddubs

3/31/2025 at 3:20:33 PM

> 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.

by renerick

3/31/2025 at 5:37:10 PM

> Now, do autocompletes

This is kind of ready, see datalist element.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...

by kkarpkkarp

4/1/2025 at 10:01:55 AM

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.

by porridgeraisin

3/31/2025 at 4:52:50 PM

<input type="datetime-local"> with automatic ISO8601 timezone offsets would be awesome too!

by preisschild

3/31/2025 at 9:29:17 PM

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.

by sublinear

3/31/2025 at 10:54:03 PM

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.

by progmetaldev

4/1/2025 at 1:00:04 PM

This works for things in the past but not things in the future.

If I say I want something to happen at 8pm New York City time on January 7, 2028 and then the DST rules for NYC change, I likely still want it to happen at 8pm. Converting to UTC and back to local time loses that information and it will happen at the wrong time.

by mason55

4/4/2025 at 4:00:48 AM

I 100% agree with you, and don't set cron jobs/scheduled tasks this way. I only use this for displaying date/time to users.

With that said, I do appreciate the comment, and would have to make sure that if I run scheduled tasks in the future, they are run when the user wishes them to be completed based on when that user sets it to be completed (so would most likely not convert to UTC, and save the timezone with the date/time).

by progmetaldev

4/4/2025 at 7:18:31 AM

I'd much rather have it just use the system time, which is already available over a javascript API. I wish it just were included in your html form datetime-local request.

https://caniuse.com/mdn-javascript_builtins_intl_datetimefor...

or appending the `Date().getTimezoneOffset();` to receive a ISO8601 timezone offset

by preisschild

4/1/2025 at 5:35:55 AM

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.

by ibejoeb

3/31/2025 at 8:00:14 PM

Ooh I can render arbitrary pixels outside the viewpoint. Like a system dialog asking for a password.

by blatantly

3/31/2025 at 1:38:52 PM

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...

by ljoshua

3/31/2025 at 2:36:53 PM

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.

by ddoolin

3/31/2025 at 2:42:03 PM

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.

by pclmulqdq

3/31/2025 at 2:53:44 PM

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

by no_wizard

3/31/2025 at 7:45:43 PM

> Even when they do arrive, they can be half baked - like dialog or details / summary - and that doesn’t help matters

How are those half-baked? No smooth transition for details/summary, maybe?

Dialog seems to work well enough with little to no javascript required:

    <dialog>
        <h3>Warning:</h3>
        ...
        <button onclick='this.closest("dialog").close()'>Dismiss</button>
    </dialog>
My personal bugbear is the date/time input - FF doesn't even show a click element for time, you have to type in the time.

by lelanthran

3/31/2025 at 8:42:59 PM

There's some quirks with the API around open vs openModal if you aren't aware of the accessibility implications you may not even realize this is the case.

Forms have some special quirks inside of a dialog.

The biggest thing though, is for the life of me I don't understand why you can't open and close a dialog without JavaScript. There's no way to do it.

by no_wizard

3/31/2025 at 11:06:31 PM

> The biggest thing though, is for the life of me I don't understand why you can't open and close a dialog without JavaScript. There's no way to do it.

You can use popovers like this without JavaScript:

    <button popovertarget="some-element" popovertargetaction="show">Open</button>
    
    <div id="some-element" popover="auto">
        <button popovertarget="some-element" popovertargetaction="hide">Close</button>
    </div>
You can mark a <dialog> element as open by default with the `open` attribute, and you can close it with a button using the `dialog` form method. No JavaScript required for that either.

I don’t think there’s any way at present to open a `<dialog>` element specifically without JavaScript, but command/commandfor handles this and was recently added to the HTML specification:

https://github.com/whatwg/html/pull/9841

by JimDabell

3/31/2025 at 8:53:51 PM

I'm with you... would be nice to have:

   <button type="open-dialog" target="dialogId">Open Dialog</button>
   ...
   <dialog id="dialogId">
     <button type="close-dialog">Close Dialog</button>
   </dialog>
It would just make so much sense.

by tracker1

4/1/2025 at 9:57:14 AM

> I'm with you... would be nice to have:

You can do this right now already:

    // For  opening
    <button onclick='document.querySelector("#dialogId").showModal()'>Open</button>

    // For closing
    <button onclick='this.closest("dialog").close()'>Close</button>
I think the problem here is that it is impossible to actually use the result from `close()`, as it can return a status, IIRC.

> It would just make so much sense.

That way above that I propose is about as sensible as the way you propose. If there are any problems with my proposal that are solved by your proposal, I'd love to hear it.

by lelanthran

4/2/2025 at 7:40:12 PM

The point was to be able to do it without JS.

by tracker1

4/3/2025 at 8:34:53 AM

I understand, but from a pragmatic viewpoint, it is no more and no less complicated to do it with `onclick` JS than it would be to do it with some other attribute.

For all practical purposes, there is no difference between the two.

I understand that the `onclick` wouldn't fire in browsers where JS is turned off, but in that case (no JS) you're going to have an awful user experience using dialogs even with builtin open/close attributes for dialogs.

by lelanthran

3/31/2025 at 10:59:53 PM

If you need to worry about ADA compliance (I always do, but not always paid to), this can be difficult to address.

I remember Opera, before it was bought, had the best support for html5 elements and date/time inputs were the best (along with almost all others). Sad to think that a leader in this area was sold off, and not to a buyer that cared about usability and the web the way Opera did.

by progmetaldev

3/31/2025 at 10:08:52 PM

You can't make enough HTML elements to make everyone happy. This was the wrong idea from the start.

by codedokode

4/1/2025 at 1:03:50 AM

The solution isn't to make a new html element for each use case.

The solution is to make html elements extensible.

With the `appearance: base-select` css rule, we now have a standardized way to extend <select> with html and css, (and we have the potential to declaratively extend intractability too with invoking commands without needing to reach for JS)

by spartanatreyu

4/1/2025 at 4:43:37 AM

I would argue you can make enough HTML elements to make enough people happy. 80% for the 80%.

by ksec

3/31/2025 at 4:29:32 PM

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.

by hombre_fatal

4/1/2025 at 4:41:26 AM

Over TWO decades late.

It is crazy to think what we only just have in anything non JavaScript in the past 20 years.

by ksec

4/1/2025 at 9:21:40 AM

It's like how border-radius was added after rounded corners via images fell out of fashion.

by Cthulhu_

3/31/2025 at 2:50:06 PM

I somehow feel Safari drags its feet on basic things platform improvements because they want to focus on iOS apps instead.

by true_religion

4/1/2025 at 1:52:40 AM

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...

by alwillis

4/1/2025 at 8:48:00 AM

The pace of improvement in the web is slow.

I don’t want to debate if a mega corp cares or not, but compared to how UI frameworks were in the 90s, the developer experience is anemic.

I don’t know if HTML, CSS and JavaScript are the best path forward. Maybe they are doing exactly what their spec set out to do.

But we need something better that doesn’t leash one to an ecosystem that takes 30% of your revenue.

by true_religion

4/1/2025 at 2:59:27 AM

[dead]

by yujohn

3/31/2025 at 3:37:56 PM

Eh; the standard is two weeks old. Written by someone working for Apple by the way.

by arp242

4/1/2025 at 8:58:32 AM

I’m wondering where in my comment it sounded like I wanted this standard specially to be implemented yesterday?

by true_religion

3/31/2025 at 2:30:45 PM

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.

by paddy_m

3/31/2025 at 2:27:29 PM

The perpetual 5 year problem of web development. I wish there was a way to do forward standards

by no_wizard

3/31/2025 at 7:18:19 PM

> 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.

by bsimpson

3/31/2025 at 2:31:09 PM

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.

by simiones

4/1/2025 at 2:07:46 PM

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.

by klysm

3/31/2025 at 2:19:45 PM

> 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.

by nasso_dev

3/31/2025 at 8:06:57 PM

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.

by dimal

3/31/2025 at 9:55:33 PM

"You" in this case is the website author. From a user perspective, that doesn't solve the problem.

by Macha

3/31/2025 at 2:23:45 PM

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.

by gruez

3/31/2025 at 4:19:12 PM

> 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.

by johannes1234321

3/31/2025 at 3:25:52 PM

you're misunderstanding, this will leave the appearance of the select on mobile up to the web developer

by asddubs

3/31/2025 at 3:30:28 PM

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.

by butz

3/31/2025 at 8:12:57 PM

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.

by dimal

3/31/2025 at 6:57:50 PM

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.

by 65

3/31/2025 at 8:15:24 PM

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`.

by KTibow

3/31/2025 at 5:29:40 PM

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.

by crazygringo

3/31/2025 at 6:55:34 PM

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.

by SoftTalker

3/31/2025 at 7:05:53 PM

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.

by crazygringo

3/31/2025 at 7:19:30 PM

Good example. There are dozens, maybe hundreds of different ways people have invented color pickers. Every app does it a little differently, meaning you have to stop and think about it every time. I'll take a simple select with the color name. If you want a swatch, put that off to the side and update it with an event handler on the select.

by SoftTalker

3/31/2025 at 7:30:40 PM

That's objectively worse, there's no way to know what "blue" means in such a context, there are many blues.

"I want things to be worse" is not a compelling argument. Letting developers describe the needs of their applications with a consistent grammar is not unnecessary invention, complexity, or friction.

The grammars of a technology, the set of building blocks with which developers are empowered to create, should balance flexibility with expressive intent. CSS <select> strikes this balance nicely. To decry its inclusion says more about the naysayer than the feature.

by nickelpro

3/31/2025 at 7:26:19 PM

Names don't fully communicate color. There are hundreds of reds. Hundreds of greens.

I don't want to have to click each green to see the swatch. Just put them in a list with swatches. That is obviously the easier UX. Nobody has to stop and think about anything.

by crazygringo

4/1/2025 at 12:49:24 AM

Windows had a standard color picker dialog that you may remember from Windows 98-Viata mspaint.

Jack of all trades, master of none. The mspaint-specific palette toolbar was much more intuitive.

by immibis

4/1/2025 at 4:13:19 AM

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.

by userbinator

3/31/2025 at 4:18:52 PM

Unfortunately those unusably small or invisible scrollbars are the default in many browsers. Such as Firefox on Linux, which I'm using right now.

by streptomycin

3/31/2025 at 4:49:27 PM

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.

by lblume

4/1/2025 at 3:31:16 AM

Exactly. It's personal preference, which means it should be the user's choice, not the site designer's.

by BrenBarn

3/31/2025 at 5:52:27 PM

Luckily Firefox allows changing that default.

by layer8

3/31/2025 at 10:15:14 PM

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)

by montag

3/31/2025 at 1:47:19 PM

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.

by dpcx

3/31/2025 at 1:55:15 PM

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.

by dqv

3/31/2025 at 2:29:02 PM

Huge miss in my opinion. If it doesn’t support all scenarios I’m not sure what the Chrome team is thinking here

by no_wizard

3/31/2025 at 7:34:20 PM

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.

by kelnos

4/1/2025 at 4:39:07 AM

They've screwed this up several times by shipping too soon and then having to backpedal. The web is not something you want to screw up because they don't own every website in existence.

by 8n4vidtmkvmk

3/31/2025 at 2:45:30 PM

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.

by dqv

3/31/2025 at 3:07:59 PM

"Select multiple" is just a list of checkboxes. The missing part (which is also missing from select) is just the filtering.

I am not holding my breath for a decent "select multiple" field. It's been the same crap for decades and browsers could have fixed it long again without waiting for spec - it's just a "replaced element", but they don't care.

The fun part is that it looks amazing on Safari iOS (and QED it's rendered as a list of checkboxes)

by sureIy

3/31/2025 at 3:45:34 PM

> "Select multiple" is just a list of checkboxes.

Not necessarily. I've seen more than one production app with a custom filtering dropdown list of items with checkboxes.

I built a couple variants of that in React at my last gig for the company's design system. The keyboard nav was complex... that component is one of the work artifacts that I'm most proud of.

by TimTheTinker

3/31/2025 at 5:07:59 PM

> custom filtering dropdown

I already said that. "Select" is not filterable in the browser already, so `select[multiple]` has no chance of seeing that in this decade.

However you slice/style it, it's just checkboxes (that you can filter/reorder)

by sureIy

3/31/2025 at 2:55:34 PM

Incremental improvement?

Why release anything right?

by pests

3/31/2025 at 6:01:36 PM

Incremental improvement is great, but I do want to know what they're thinking here.

They didn't mention it in the blog post that multiple isn't supported. Its perfectly fine if it is not supported right now. It would be great if they acknowledged that up front to set expectations accordingly.

For instance, if its explicitly not supported, then I won't be left wondering if its a bug or a misunderstanding of the implementation etc.

Communication would be really good here. I'm all for incremental improvement, I think we need more of it.

Doesn't mean there shouldn't be better communication about it.

by no_wizard

3/31/2025 at 8:14:10 PM

In the original dev blog from last year they mention it’s still a work in progress.

https://developer.chrome.com/blog/rfc-customizable-select

> Note: The multiple and size attributes on select (<select multiple> and <select size=n>) are not supported in appearance: base-select yet.

by pests

3/31/2025 at 8:45:57 PM

From last year while it was a WIP

and now this as of Chrome 135 is shipped, and they didn't think it wise to include a back reference to this post, calling out what isn't supported?

They can and should communicate this is all.

by no_wizard

4/1/2025 at 6:38:01 AM

Agreed. Should have mentioned it in this post or at least linked back to my source.

by pests

3/31/2025 at 2:02:45 PM

That really sucks :/

by zachrip

3/31/2025 at 2:12:54 PM

> 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.

by Contax

3/31/2025 at 2:43:34 PM

The <select> element can now be customized with CSS *in Chromium browsers*

by chias

4/1/2025 at 7:15:29 AM

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.

by robin_reala

3/31/2025 at 9:24:13 PM

Can't wait to use it in 2030 when my work stops supporting IE11

by indie_architect

3/31/2025 at 11:21:38 PM

Don't worry, they'll get extended support. Again.

by olyjohn

3/31/2025 at 7:20:02 PM

Damn... been wanting this for well over two decades. About time. Still missing a good combo-box and type-ahead solution from the box.

by tracker1

3/31/2025 at 2:07:29 PM

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.

by klabb3

3/31/2025 at 2:14:43 PM

>> 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.

by pests

3/31/2025 at 2:41:02 PM

Can we have a fully native combobox now?

by Onavo

3/31/2025 at 4:48:17 PM

This is badly needed. Until we have combobox, the <select> is best implemented as a readonly combobox, because you need to implement combobox in any case.

by breadwinner

3/31/2025 at 10:02:14 PM

Making web standards even more complicated one change at a time.

by codedokode

3/31/2025 at 1:50:38 PM

Finally! This is incredibly good news. I hope the adoption of this feature is fast - looking at you Safari.

by johnthuss

3/31/2025 at 4:00:26 PM

Looks pretty broken in FF 136.0.2 (missing backgrounds/boxes, the popoup menus are visible).

by ichik

4/1/2025 at 9:33:39 AM

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.

by earcar

3/31/2025 at 10:06:29 PM

If they keep this up, we'll soon have feature parity with VB6.

by peteforde

3/31/2025 at 6:27:58 PM

Love the fact that Google auto translate of the page completely breaks the page

https://imgur.com/7gfXRrm

by cellover

3/31/2025 at 8:33:03 PM

This is also very much how the page looks for me in Firefox. If it can't fail without issues it's not an option I'd select.

by nedt

3/31/2025 at 8:35:29 PM

Oh ... it's actually their own integrated translation that breaks it. Now that's funny. They aren't escaping correctly. Now if someone wants to play around with that ...

by nedt

4/1/2025 at 1:22:51 AM

what's to love about this?

by efilife

3/31/2025 at 7:40:55 PM

Why would this be preferred over creating a new HTML element, like <options>?

by largehotcoffee

3/31/2025 at 9:29:27 PM

Backwards compatibility. Older browsers will still be able to render the <select> and submit it as part of a form, just with its options unstyled.

by minitech

3/31/2025 at 7:21:34 PM

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:

    option:after {
      content: ' (' attr(data-descr) ')';
    }

    <select>
      <option data-descr="some description">Foo</option>
      <option data-descr="some other stuff">Bar</option>
    </select>
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.

by kelnos

4/1/2025 at 1:17:58 AM

`attr()` has had terrible support which is a shame because it's been around for ages and could have let us do a lot of things without having to implement stuff manually.

There's another way to try it though...

I'd try putting two separate <span>s inside each option, one for the short description and one for the long description.

I'd hide one span with css if it was inside an <option> tag.

I'd hide the other span if it was inside a <selectedoption> tag.

That would probably work.

The papercut would be that when gracefully degrading back to an ordinary select element, it might show both the short and the long selections which depending on how you write the content may or may not be an issue.

by spartanatreyu

4/1/2025 at 5:00:11 AM

Ignoring this new feature, you can't put spans inside an option, only text. It's odd that they have this example in the post for the "old" way but they show it retaining the spans.

by zerocrates

4/1/2025 at 11:27:50 PM

You can put <span>s inside an <option>. The <option>'s `innerText` is used to populate the native control's label, meaning the inside of the spans are too.

The problem is that you can't target the span in the original parser.

But, you could use a template, since it's contents are ignored by text content parsers.

You can have your option as:

<option value="red"> <span>Normal Difficulty</span> <template>- The way it's meant to be played</template> </option>

With the original parser, this will be parsed as:

<option value="red">Normal Difficulty</option>

And with the new parser (so long as you opt into it with the `appearance: base-select` rule):

<option value="red"> <span>Normal Difficulty</span> <template>- The way it's meant to be played</template> </option>

---------------------------

Then once you've opted into the new parser, you can target both the span and template to render how you want. (e.g. Give span a larger font-weight, give template a display mode of block and italicised text)

by spartanatreyu

4/2/2025 at 8:01:17 PM

Sure you can do it with this new feature.

I assumed your comment was trying to give the parent commenter a strategy that would work with the "classic" select but I see now that you mentioned "selectedoption" so you were talking about the new one.

by zerocrates

4/1/2025 at 9:00:18 AM

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

by paradox460

3/31/2025 at 1:51:23 PM

Can someone explain why this took them literal decades to do?

by jillyboel

3/31/2025 at 2:24:02 PM

As I remember the arguments from 20 years ago, there was strong pushback against changing any form inputs, which the people who did such work said should appear as the operating system itself styled them (so users would recognize them as form inputs).

Should be able to style more than just selects, after all. Why the fuck can't I change the mask character in a password field to be something other than bullets? Hah. I had better examples too, but it looks like in the past 10 years or so, they've slowly been CSS-ized. Nice. Now if I could just style half the first line (first-line does the entirety of the line or nothing).

by NoMoreNicksLeft

3/31/2025 at 1:56:17 PM

There is no one truly in charge, it's a distributed standard

by Nesco

3/31/2025 at 10:05:37 PM

Because HTML historically was designed for marking up text articles by hand rather than building UI with tools.

by codedokode

3/31/2025 at 2:08:00 PM

Priorities? Profit incentives?

by LoganDark

3/31/2025 at 7:58:46 PM

> Changes the browsers HTML parser

Sounds like you can create loops. If the select had a style element that turns this off again would it keep changing state?

by blatantly

4/1/2025 at 10:59:42 AM

I don't see how it would create a loop? It seems like the parser change only impacts <select>'s descendant elements (to stop "cleaning" them of illegal elements), not <select> itself.

by vntok

3/31/2025 at 6:10:36 PM

Been waiting for this - hopefully this inspires more native web features to be implemented so devs can reduce their reliance on dependencies

by Brysonbw

4/1/2025 at 4:43:50 AM

There should be a search box by default at the top of any <select> dropdown if there are more than n items

by AbuAssar

3/31/2025 at 8:44:02 PM

Wow what's next, scrolling title text? What a time to be alive...

by ilayn

3/31/2025 at 8:56:02 PM

trying to write automation js for material ui dropdowns has been a PITA. This is the right direction!!

by darepublic

3/31/2025 at 8:20:12 PM

So how long until Safari adopts this?

by pier25

3/31/2025 at 3:26:35 PM

hey, this is about 20 years late.

by sleepybrett

3/31/2025 at 9:14:16 PM

It's been 84 years...

by renegade-otter

3/31/2025 at 5:50:41 PM

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.

by hk1337

4/1/2025 at 11:41:36 AM

I'm sitting here for a few years already, happily using Safari as my main driver. Recently switched to Orion to get Safari + Chrome/FF plugins. Best combination.

Easy on the battery, freaking fast, low ram usage, and plugin support (ALSO on iOS, yes, uBlock on iOS). Screw firefox, screw chrome.

Yes, I also dev on Orion. The dev tools are fine.

by jeffhuys

4/1/2025 at 2:11:43 PM

One of the main features I love about Safari is that in private browsing mode, the tabs (at least) appear to be completely isolated.

If I go to Facebook and login in one tab, then open a second tab and go Facebook, it doesn't recognize that I have logged in. There's moments where that is annoying but most of the time it's useful.

by hk1337

4/1/2025 at 2:23:51 PM

Yeah they are, which is IMO a good thing but it'd be better if you could link them somehow, maybe have a temporary session or something.

by jeffhuys

3/31/2025 at 1:50:16 PM

Oh my god. This has got to be like 20 years in the making

by oliv__

3/31/2025 at 4:19:34 PM

I'd love to know the opportunity cost - billions?

by rbrownmh

3/31/2025 at 8:30:10 PM

The cost of browsers not having extremely-basic things that they either started to implement then abandoned in a nigh-useless state (login, frames) or never even tried to have but really, really should have once it was clear "web apps" were here to stay (datasource-backed lists and tables, table sorting without more custom JS than a sort function, drag-n-drop) is truly enormous. Who knows how many millions of person-hours.

by alabastervlog

3/31/2025 at 3:53:07 PM

Now how do I add an text input filter? Is that another 20 year wait? :-)

by johnfn

4/1/2025 at 12:48:29 PM

Great! Now what about webtransport in WebKit?

by sbussard

4/1/2025 at 3:31:58 AM

Oh joy. Another way for website designers to override user display preferences.

by BrenBarn

4/1/2025 at 10:51:52 AM

On the contrary. It's CSS, you can change all of this in your browser's CSS overrides if you want.

by vntok

3/31/2025 at 1:34:31 PM

[dead]

by T3RMINATED

4/3/2025 at 12:52:32 PM

[dead]

by clownpenis_fart

3/31/2025 at 5:47:10 PM

in Chrome :wince: I honestly wish they didn't add this

by dmvjs

3/31/2025 at 2:15:59 PM

First time I had the idea of building UI for apps using web technologies was in 2009 I suppose. These were the times of MFC/ATL/WinForms/GTK etc.

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.

by wg0

3/31/2025 at 3:06:53 PM

Developers, don't fall for this!

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.

by zb3

3/31/2025 at 3:14:50 PM

> and firefox will become even less relevant

No; Firefox can easily afford financially to add this feature. Firefox is already irrelevant; no developer will shed a tear about just blocking Firefox if they refuse to implement. Boycotting won't work either, because boycotts almost never work.

by gjsman-1000

3/31/2025 at 4:55:16 PM

> Firefox is already irrelevant

Did I miss anything?

It’s still not as clumsy and resource intensive (while destroying hardware like disks) like Chrome..

by misiek08

3/31/2025 at 7:46:41 PM

GP means irrelevant in the sense that Firefox's market share is so low that web devs need not test on it or ensure compatibility.

This saddens me, as a Firefox user, but we have Mozilla's inept management to blame for this.

by kelnos

3/31/2025 at 10:04:32 PM

Firefox doesn't have ad measurement and interests sharing built in yet (or am I wrong?) so it is very relevant for me. I would rather use black-and-white selects everywhere rather than having an advertising engine built into the browser.

by codedokode

3/31/2025 at 11:29:33 PM

You are indeed wrong.

https://support.mozilla.org/en-US/kb/privacy-preserving-attr...

by tredre3

4/1/2025 at 10:04:27 AM

That is disappointing. I went into settings to turn this off but it is already turned off and I don't remember whether I did it or my distribution ships Firefox with non-recommended settings. I hope it is the latter so that I don't get disappointed in Linux distributions also.

"Privacy preserving attribution" sounds like "money preserving robbery" (or money preserving tax).

by codedokode