Puan
28,728
Çözümler
0
- Konum
- Freanchey
- Mesajlar
- 3,049
- Katılım
- 2 Eki 2026
- Tepkime puanı
- 3,565
- Puan
- 28,728
- Web sitesi
- glomaxgpt.com
Just looking at what Bramus shared the other day:
/* Adding a base class */
.btn {
/* Listing everything... yuck! */
.btn-primary,
.btn-secondary,
.btn-danger {
/* Works, but performs badly */
[class^="btn-"],
[class*=" btn-"] {
/* Newly resolved class prefix selector */
.btn-* {
First off, if you don’t follow Bramus, where have you been?! Jokes aside, his job is to be first-in-line on new features like this — especially as it pertains to Chrome — so it’s worth keeping tabs on his RSS and/or social.
It’s not a new proposal. Lea posted it back in 2024 and has advocated for it the whole while. As Bramus mentions in his post, what’s new is that the proposal was formally adopted and, as of three days ago, it has been added to the Selectors Level 5 spec draft. So, chances are that we’ll see it formally adopted at some point and implemented somewhere even sooner.
I really like the ergonomics of it. Existing substring selectors — class^="prefix" and class=*" prefix" — are verbose and defintely less readable than a simple .prefix-*.
And it’s not like [data-attribute] selectors that require not only an extra step touching HTML but still added verbosity.
But something makes me wince at the idea. I can’t quite put my finger on it. Perhaps it’s redundancy as in, we can already do this with existing selectors? Bramus cites performance issues with existing substring selectors as a primary reason we need this. But Brian Kardell’s reply resonates with me:
Yeah, I guess if we have a very specific case we can optimize it more than a general one, but I'm not seeing how this is a lot more specific than the version above which almost exists today. Feels like if we could optimize this we could optimize that. I'd be curious how it is optimized.— Brian Kardell (@bkardell.com) 2026-08-20T15:43:02.158Z
Then again, I do like how we extended color functions for brevity, like:
/* Adding a base class */
.btn {
/* Listing everything... yuck! */
.btn-primary,
.btn-secondary,
.btn-danger {
/* Works, but performs badly */
[class^="btn-"],
[class*=" btn-"] {
/* Newly resolved class prefix selector */
.btn-* {
First off, if you don’t follow Bramus, where have you been?! Jokes aside, his job is to be first-in-line on new features like this — especially as it pertains to Chrome — so it’s worth keeping tabs on his RSS and/or social.
It’s not a new proposal. Lea posted it back in 2024 and has advocated for it the whole while. As Bramus mentions in his post, what’s new is that the proposal was formally adopted and, as of three days ago, it has been added to the Selectors Level 5 spec draft. So, chances are that we’ll see it formally adopted at some point and implemented somewhere even sooner.
I really like the ergonomics of it. Existing substring selectors — class^="prefix" and class=*" prefix" — are verbose and defintely less readable than a simple .prefix-*.
And it’s not like [data-attribute] selectors that require not only an extra step touching HTML but still added verbosity.
But something makes me wince at the idea. I can’t quite put my finger on it. Perhaps it’s redundancy as in, we can already do this with existing selectors? Bramus cites performance issues with existing substring selectors as a primary reason we need this. But Brian Kardell’s reply resonates with me:
Yeah, I guess if we have a very specific case we can optimize it more than a general one, but I'm not seeing how this is a lot more specific than the version above which almost exists today. Feels like if we could optimize this we could optimize that. I'd be curious how it is optimized.— Brian Kardell (@bkardell.com) 2026-08-20T15:43:02.158Z
Then again, I do like how we extended color functions for brevity, like: