Why would this be preferred over creating a new HTML element, like ?
The element can now be customized with CSS
91–100 of 194 posts
Re: The <select> element can now be customized with CSS
#92Earlier quoted context omitted.
Because frontend is frontend, Javascript frameworks dominated the conversation even for silly things like basic web forms for the past 15 years. Basic HTML/CSS is now catching up to the fact that not everyone wants to run a Javascript monstrosity for custom styling on very basic tasks.
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…
> Even when they do arrive, they can be half baked - like dialog or details / summary - and that doesn’t help matters
How are those half-baked? No smooth transition for details/summary, maybe?
Dialog seems to work well enough with little to no javascript required:
Warning:
...
Dismiss
Re: The <select> element can now be customized with CSS
#93Earlier quoted context omitted.
> and firefox will become even less relevant No; Firefox can easily afford financially to add this feature. Firefox is already irrelevant; no developer will shed a tear about just blocking Firefox if they refuse to implement. Boycotting won't work either, because boycotts almost never work.
> Firefox is already irrelevant Did I miss anything? It’s still not as clumsy and resource intensive (while destroying hardware like disks) like Chrome..
GP means irrelevant in the sense that Firefox's market share is so low that web devs need not test on it or ensure compatibility.
This saddens me, as a Firefox user, but we have Mozilla's inept management to blame for this.
Re: The <select> element can now be customized with CSS
#94Re: The <select> element can now be customized with CSS
#95Earlier quoted context omitted.
I have, and failed. See https://news.ycombinator.com/item?id=40265782
Safari is the "new" IE. I put "new" in quotes because it's been this way for like a decade.
--- start quote ---
Back fifteen years ago IE held back the web because web developers had to cater to its outdated technology stack. “Best viewed with IE” and all that. But do you ever see a “Best viewed with Safari” notice? No, you don’t. Another browser takes that special place in web developers’ hearts and minds.
--- end quote ---
https://www.quirksmode.org/blog/archives/2021/08/breaking_th...
Re: The <select> element can now be customized with CSS
#96> Changes the browsers HTML parser
Sounds like you can create loops. If the select had a style element that turns this off again would it keep changing state?
Re: The <select> element can now be customized with CSS
#97The 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...
Ooh I can render arbitrary pixels outside the viewpoint. Like a system dialog asking for a password.
Re: The <select> element can now be customized with CSS
#98> 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.
This is only if you opt in to base-select, so if you don't use that, everything should continue to work the same, as far as I can tell.
Re: The <select> element can now be customized with CSS
#99Some 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.
This ship sailed in 2000. We've been hacking custom select boxes since then, so we may as well pave the cowpath. And besides, as a user, I want stylable select elements. Seeing an ugly old select box in the middle of a site where everything is styled consistently is jarring.
And it doesn't get the job done. You can't put stuff like SVGs or complex DOM elements in them, which is a valid use case. Most of the time, when people create custom select boxes, they ignore accessibility. This will fix that issue.
Re: The <select> element can now be customized with CSS
#100Earlier quoted context omitted.
Incremental improvement? Why release anything right?
Incremental improvement is great, but I do want to know what they're thinking here. They didn't mention it in the blog post that multiple isn't supported. Its perfectly fine if it is not supported right now. It would be great if they acknowledged that up front to set expectations accordingly. For instance, if its explicitly not supported, then I won't be left wondering if its a bug or a misunderstanding of the implem…
In the original dev blog from last year they mention it’s still a work in progress.
https://developer.chrome.com/blog/rfc-customizable-select
> Note: The multiple and size attributes on select ( and ) are not supported in appearance: base-select yet.