←back to thread

The <select> element can now be customized with CSS

(developer.chrome.com)
497 points tosh | 7 comments | 31 Mar 25 09:11 UTC | HN request time: 1.237s | source | bottom
Show context
butz ◴[31 Mar 25 15:30 UTC] No.43536187[source]▶
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.
replies(6): >>43536730 #>>43537510 #>>43538464 #>>43539356 #>>43540555 #>>43542772 #
1. crazygringo ◴[31 Mar 25 17:29 UTC] No.43537510[source]▶
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.
replies(1): >>43538439 #
2. SoftTalker ◴[31 Mar 25 18:55 UTC] No.43538439[source]▶
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.
replies(1): >>43538557 #
3. crazygringo ◴[31 Mar 25 19:05 UTC] No.43538557[source]▶
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.

replies(1): >>43538706 #
4. SoftTalker ◴[31 Mar 25 19:19 UTC] No.43538706{3}[source]▶
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.
replies(3): >>43538801 #>>43538855 #>>43541680 #
5. crazygringo ◴[31 Mar 25 19:26 UTC] No.43538801{4}[source]▶
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.

6. nickelpro ◴[31 Mar 25 19:30 UTC] No.43538855{4}[source]▶
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.

7. immibis ◴[01 Apr 25 00:49 UTC] No.43541680{4}[source]▶
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.