Live data from Hacker News

The element can now be customized with CSS

developer.chrome.com

11–20 of 194 posts

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

#11
post #9
post #5

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.

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.

That really sucks :/

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

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

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

#14
post #5

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.

> This looks like what web developers have been waiting literally decades for.

Count me in. Most times it didn't matter to me but there were some cases when I wanted or needed them to have a specific style matching other elements and, yes, I could only do it -to the best I knew- with JS.

Let's see if it becomes widely supported.

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

#15
post #12

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

>> It doesn't trigger built-in mobile operating system components.

>Yeah so this is scary, but how is layouting done then?

Via HTML in-website, not via opening the android wheel picker or anything like that.

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

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

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

#17
> 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 , but also date/time inputs for example.

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

#18

> 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 , but also date/time inputs for example.

Chrome already uses plenty of non-native components. Firefox is similar. Moreover while I can understand the concern about poorly implemented components from random web developers, Google is probably the best positioned to implement a widget that faithfully replicates the native equivalent, at least on Android.

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

#19

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

As I remember the arguments from 20 years ago, there was strong pushback against changing any form inputs, which the people who did such work said should appear as the operating system itself styled them (so users would recognize them as form inputs).

Should be able to style more than just selects, after all. Why the fuck can't I change the mask character in a password field to be something other than bullets? Hah. I had better examples too, but it looks like in the past 10 years or so, they've slowly been CSS-ized. Nice. Now if I could just style half the first line (first-line does the entirety of the line or nothing).

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

#20
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…

The perpetual 5 year problem of web development. I wish there was a way to do forward standards
Post reply on HN