The point of Chrome-only CSS (vendor-prefixed features) would be to allow Chrome or any other vendor to expose styling functionality to CSS authors in valid CSS syntax in ways that won't impede future standardization efforts (like writing non-standard CSS would do) or interfere with that same CSS being processed by other vendors.
But this article isn't an example of Chrome-only CSS, this is about a change to the standard select element to make it customizeable in a standard way. It's not fully frozen yet, so they're seeking feedback and still working on it, so if you have input to give about this feature I think they'd welcome it. This blog post was about Chrome introducing experimental support for it, likely so developers can experiment with it and provide more valuable feedback towards its standardization!
Why dont you read the article and see for yourself.
> A customizable version of the select element is officially in Stage 2 in the WHATWG, with strong cross-browser interest and a prototype for you to test out from Chrome Canary 130.
> Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that".
It's absolutely not that- it's an early implementation of a drafted WHATWG standard in the "iteration" phase, put behind a development build and a development flag so people know that it isn't stable and might change and nobody who doesn't explicitly opt in will be affected. This is literally made to allow "people who try to set some standards" to test their proposed standards and iterate on them before finalizing the proposal.
As far as accessibility, the native browser select is almost always going to be more accessible than someone making a custom input using JavaScript so they can add some styling control. Having the native version support basic styling is a big accessibility win IMO, because it disincentives developers from making a less accessible alternative for the sake of matching some design file.
The middle finger is for people like you who didnt read the first paragraph.
> A customizable version of the select element is officially in Stage 2 in the WHATWG, with strong cross-browser interest and a prototype for you to test out from Chrome Canary 130.
The point of Chrome-only CSS (vendor-prefixed features) would be to allow Chrome or any other vendor to expose styling functionality to CSS authors in valid CSS syntax in ways that won't impede future standardization efforts (like writing non-standard CSS would do) or interfere with that same CSS being processed by other vendors.
But this article isn't an example of Chrome-only CSS, this is about a change to the standard select element to make it customizeable in a standard way. It's not fully frozen yet, so they're seeking feedback and still working on it, so if you have input to give about this feature I think they'd welcome it. This blog post was about Chrome introducing experimental support for it, likely so developers can experiment with it and provide more valuable feedback towards its standardization!
Reminds me of when we had to use browser hacks for IE.
So websites "look better in Chrome", that's what Google wants.. but it's ultimately not good for us, so I hope developers don't fall for this..
Why dont you read the article and see for yourself.
> A customizable version of the select element is officially in Stage 2 in the WHATWG, with strong cross-browser interest and a prototype for you to test out from Chrome Canary 130.
This doesn't change the fact that it will only work in Chrome for a long time before it ships to firefox.
2 replies →
[flagged]
https://news.ycombinator.com/newsguidelines.html
> Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that".
It's a middle finger to people who try to set some standards and maintain them for a while. Also, a middle finger to accessibility people.
It's absolutely not that- it's an early implementation of a drafted WHATWG standard in the "iteration" phase, put behind a development build and a development flag so people know that it isn't stable and might change and nobody who doesn't explicitly opt in will be affected. This is literally made to allow "people who try to set some standards" to test their proposed standards and iterate on them before finalizing the proposal.
As far as accessibility, the native browser select is almost always going to be more accessible than someone making a custom input using JavaScript so they can add some styling control. Having the native version support basic styling is a big accessibility win IMO, because it disincentives developers from making a less accessible alternative for the sake of matching some design file.
The middle finger is for people like you who didnt read the first paragraph.
> A customizable version of the select element is officially in Stage 2 in the WHATWG, with strong cross-browser interest and a prototype for you to test out from Chrome Canary 130.