Just looking at what Bramus shared the other day:

/* Adding a base class */
.btn {
  padding: 0.5rem 1rem;
  border-radius: 4px;
}

/* Listing everything... yuck! */
.btn-primary,
.btn-secondary,
.btn-danger {
  padding: 0.5rem 1rem;
  border-radius: 4px;
}

/* Works, but performs badly */
[class^="btn-"],
[class*=" btn-"] {
  padding: 0.5rem 1rem;
}

/* Newly resolved class prefix selector */
.btn-* {
  padding: 0.5rem 1rem;
  border-radius: 4px;
}

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:

Then again, I do like how we extended color functions for brevity, like:

/* old */
color: rgba(10%, 20%, 20%, .25);

/* new */
color: rgb(10, 20, 20 / .25);

And it’s backwards-compatible, so no real harm if you continue to use the “old” way. It’s not like substring selectors don’t have other use cases and become totally obsolete. But maybe that’s it: this isn’t an “upgrade” of something we already have, but a new thing that isn’t progressive enhancement out of the gate. We’d have to @support it until it becomes a Baseline feature:

@supports selector(.prefix-*) {
  /* ... */
}

…which may or may not be a long wait. But we don’t know. And if ergonomics are the selling point, then we’re losing that in the wait.

Should also note that the wildcard doesn’t match other conditions or non-dashed cases:

/* Nope */
.prefix* {}
.prefix-*-suffix {}
.prefix_* {} /* the door is left open on this */

Another worthy note is that the spec currently implies (but doesn’t explicitly state) that this has the same specificity as a class selector, (0,1,0). That’d make sense, as .prefix-* is really no different than writing .prefix-variation.

That said, I like how it might possibly look in a nested syntax:

.prefix {
  /* This would work, right? */
  &-* { /* ... */ }
}

…and Dave’s plea to support selecting web components:

Maybe I just convinced myself that I like it. Again, I dunno. Just take the added convenience and move on! Yada yada.

Direct Link →