Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The element can now be customized with CSS

developer.chrome.com

Post reply on HN
Print view View original

81–90 of 194 posts

Re: The <select> element can now be customized with CSS

#81

Post by 65 »

butz wrote: post #46

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.

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.

Re: The <select> element can now be customized with CSS

#82

Post by crazygringo »

SoftTalker wrote: post #79
crazygringo wrote: post #65

Earlier quoted context omitted.

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.

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.

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.

Re: The <select> element can now be customized with CSS

#84

Post by bsimpson »

ljoshua wrote: post #3

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 pr…

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

Re: The <select> element can now be customized with CSS

#85

Post by SoftTalker »

crazygringo wrote: post #82
SoftTalker wrote: post #79

Earlier quoted context omitted.

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.

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…

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.

Re: The <select> element can now be customized with CSS

#87

Post by kelnos »

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 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 , so something like this:

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

    
      Foo
      Bar
Unfortunately this just doesn't work (I presume because can't contain DOM elements aside from unstyled text), but I wonder if it will work now.

Re: The <select> element can now be customized with CSS

#88

Post by crazygringo »

SoftTalker wrote: post #85
crazygringo wrote: post #82

Earlier quoted context omitted.

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…

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.

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.

Re: The <select> element can now be customized with CSS

#89

Post by nickelpro »

SoftTalker wrote: post #85
crazygringo wrote: post #82

Earlier quoted context omitted.

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…

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.

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 strikes this balance nicely. To decry its inclusion says more about the naysayer than the feature.

Re: The <select> element can now be customized with CSS

#90

Post by kelnos »

no_wizard wrote: post #21
dqv wrote: post #9

Earlier quoted context omitted.

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.

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

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.

Post reply on HN