Top
Best
New

Posted by tosh 3/31/2025

The <select> element can now be customized with CSS(developer.chrome.com)
507 points | 187 commentspage 2
Onavo 3/31/2025|
Can we have a fully native combobox now?
breadwinner 3/31/2025|
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.
codedokode 3/31/2025||
Making web standards even more complicated one change at a time.
johnthuss 3/31/2025||
Finally! This is incredibly good news. I hope the adoption of this feature is fast - looking at you Safari.
ichik 3/31/2025||
Looks pretty broken in FF 136.0.2 (missing backgrounds/boxes, the popoup menus are visible).
peteforde 3/31/2025||
If they keep this up, we'll soon have feature parity with VB6.
earcar 4/1/2025||
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.

cellover 3/31/2025||
Love the fact that Google auto translate of the page completely breaks the page

https://imgur.com/7gfXRrm

nedt 3/31/2025||
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.
nedt 3/31/2025||
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 ...
efilife 4/1/2025||
what's to love about this?
largehotcoffee 3/31/2025||
Why would this be preferred over creating a new HTML element, like <options>?
minitech 3/31/2025|
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.
kelnos 3/31/2025|
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.
spartanatreyu 4/1/2025|
`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.

zerocrates 4/1/2025||
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.
spartanatreyu 4/1/2025||
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)

zerocrates 4/2/2025||
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.

More comments...