HN Reader

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

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

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

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

firefox issue https://bugzilla.mozilla.org/show_bug.cgi?id=1944403

Oh the irony of the Chrome dev blog failing Google's own Core Web Vitals test

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

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

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.

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

Can we have a fully native combobox now?

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

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

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

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.

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

https://imgur.com/7gfXRrm

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

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.

It's been 84 years...

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

hey, this is about 20 years late.

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.

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

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

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

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

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

So how long until Safari adopts this?

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

Great! Now what about webtransport in WebKit?

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

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

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

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.

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.

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