| ▲ | Sateeshm 2 days ago |
| What's the point of Chrome-only css. |
|
| ▲ | err4nt 2 days ago | parent | next [-] |
| 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! |
|
| ▲ | chente 2 days ago | parent | prev | next [-] |
| Reminds me of when we had to use browser hacks for IE. |
|
| ▲ | zb3 2 days ago | parent | prev | next [-] |
| 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.. |
| |
| ▲ | bitpush 2 days ago | parent [-] | | 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. | | |
| ▲ | zb3 a day ago | parent [-] | | This doesn't change the fact that it will only work in Chrome for a long time before it ships to firefox. | | |
| ▲ | bitpush 17 hours ago | parent | next [-] | | So? Damned if you do, damned if you don't? Don't do something - OMG, Chrome is dragging their feet. Why can't they do it? It is standards track after all Do something - umm, it'll be only on Chrome for a really long time. At least be a bit consistent with your qualms. | |
| ▲ | decremental a day ago | parent | prev [-] | | [dead] |
|
|
|
|
| ▲ | bitpush 2 days ago | parent | prev | next [-] |
| [flagged] |
| |
|
| ▲ | drivingmenuts 2 days ago | parent | prev [-] |
| 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. |
| |
| ▲ | naet 2 days ago | parent | next [-] | | 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. | |
| ▲ | bitpush 2 days ago | parent | prev [-] | | 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. |
|
