Live data from Hacker News

The element can now be customized with CSS

developer.chrome.com

141–150 of 194 posts

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

#141

Earlier quoted context omitted.

The prevalence of JS and JS backed components is due to the reluctance of browser vendors to introduce new HTML elements that everyone has been lobbying for in the same time period. By and large browser vendors for the longest time, even today still in many respects, repeatedly ignore pleas for more elements that cover common use cases. Even when they do arrive, they can be half baked - like dialog or details / summa…

You can't make enough HTML elements to make everyone happy. This was the wrong idea from the start.

The solution isn't to make a new html element for each use case.

The solution is to make html elements extensible.

With the `appearance: base-select` css rule, we now have a standardized way to extend with html and css, (and we have the potential to declaratively extend intractability too with invoking commands without needing to reach for JS)

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

#142
post #27

The element can now be customized with CSS *in Chromium browsers*

So at least 5 more years until in can actually be used.

Firefox already has indicated that they approve of the new proposal: https://github.com/mozilla/standards-positions/issues/1060

We're only waiting on Safari now: https://github.com/WebKit/standards-positions/issues/386

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

#143
post #87

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

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

I'd hide the other span if it was inside a 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.

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

#145
post #24

Earlier quoted context omitted.

I agree that this is a huge improvement, but it's also over a decade late IMO. This should've been accomplished well before now, especially given that the issue has been there since the beginning.

I somehow feel Safari drags its feet on basic things platform improvements because they want to focus on iOS apps instead.

The narrative Safari is behind and Apple doesn’t care about the web is so tired…

This 8,000+ word article on Safari 18.4 (released today, BTW) doesn’t read like an organization that doesn’t care about the web [1].

[1]: https://webkit.org/blog/16574/webkit-features-in-safari-18-4...

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

#146
post #76
post #52

Earlier quoted context omitted.

Definitely not. Why would they let web devs render outside of the browser window? That's a recipe for disaster.

There needs to be some middle ground. I'd trade off just being able to set just the background color and font and keep these native-like features

The following works for me in Chrome, and doesn't prevent the menu from going outside of the viewport:

    select, option {
        background: red;
        font-family: 'comic sans ms';
    }

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

#147
post #50

Earlier quoted context omitted.

I have, and failed. See https://news.ycombinator.com/item?id=40265782

It may not be present in Apple’s official documentation but it has been supported since Safari 12.2. See https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da... compatibility. The demo on that page works for me in current Safari on both iOS and Mac.

Some examples seem to work better than others though. I’m on latest iOS and sometimes it will invoke the native date picker like you’d expect to see, sometimes it won’t, and the type ahead doesn’t seem to work consistently

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

#148

Earlier quoted context omitted.

I somehow feel Safari drags its feet on basic things platform improvements because they want to focus on iOS apps instead.

The narrative Safari is behind and Apple doesn’t care about the web is so tired… This 8,000+ word article on Safari 18.4 (released today, BTW) doesn’t read like an organization that doesn’t care about the web [1]. [1]: https://webkit.org/blog/16574/webkit-features-in-safari-18-4...

[dead]

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

#149

Earlier quoted context omitted.

You can't make enough HTML elements to make everyone happy. This was the wrong idea from the start.

The solution isn't to make a new html element for each use case. The solution is to make html elements extensible. With the `appearance: base-select` css rule, we now have a standardized way to extend with html and css, (and we have the potential to declaratively extend intractability too with invoking commands without needing to reach for JS)

> The solution is to make html elements extensible.

The solution would be to make Apple ship this:

https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...

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

#150
post #61

Earlier quoted context omitted.

Unfortunately those unusably small or invisible scrollbars are the default in many browsers. Such as Firefox on Linux, which I'm using right now.

I think this really comes down to personal preference. I also use Firefox on Linux and always find the Windows-type scrollbar to be incredibly ugly and bulky, especially on other overflow: scroll elements.

Exactly. It's personal preference, which means it should be the user's choice, not the site designer's.
Post reply on HN