←back to thread

The <select> element can now be customized with CSS

(developer.chrome.com)
507 points tosh | 1 comments | 31 Mar 25 09:11 UTC | HN request time: 0.207s | source
Show context
wolframhempel ◴[31 Mar 25 15:14 UTC] No.43535984[source]▶
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...

replies(6): >>43536012 #>>43536059 #>>43536090 #>>43537120 #>>43537585 #>>43539203 #
asddubs ◴[31 Mar 25 15:22 UTC] No.43536090[source]▶
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

replies(5): >>43536161 #>>43537035 #>>43537996 #>>43539933 #>>43541655 #
Eric_WVGG ◴[31 Mar 25 16:44 UTC] No.43537035[source]▶
"It doesn't trigger built-in mobile operating system components." Is that part of the spec? I can see Apple deviating from that implementation.
replies(1): >>43538461 #
1. jraph ◴[31 Mar 25 18:57 UTC] No.43538461[source]▶
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)