Resolved: CSS Class Prefix Selector

Simply taking a look at what Bramus shared the opposite day:

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

/* Itemizing the whole lot... yuck! */
.btn-primary,
.btn-secondary,
.btn-danger {
  padding: 0.5rem 1rem;
  border-radius: 4px;
}

/* Works, however 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, in case you don’t comply with Bramus, the place have you ever been?! Jokes apart, his job is to be first-in-line on new options like this — particularly because it pertains to Chrome — so it’s value preserving tabs on his RSS and/or social.

It’s not a brand new proposal. Lea posted it again in 2024 and has advocated for it the entire whereas. As Bramus mentions in his submit, what’s new is that the proposal was formally adopted and, as of three days in the past, it has been added to the Selectors Stage 5 spec draft. So, likelihood is that we’ll see it formally adopted sooner or later and applied someplace even sooner.

I actually just like the ergonomics of it. Current substring selectors — class^="prefix" and class=*" prefix" — are verbose and defintely much less readable than a easy .prefix-*.

And it’s not like [data-attribute] selectors that require not solely an additional step touching HTML however nonetheless added verbosity.

However one thing makes me wince on the thought. I can’t fairly put my finger on it. Maybe it’s redundancy as in, we are able to already do that with current selectors? Bramus cites efficiency points with current substring selectors as a main cause we’d like this. However Brian Kardell’s reply resonates with me:

Then once more, I do like how we prolonged colour capabilities for brevity, like:

/* previous */
colour: rgba(10%, 20%, 20%, .25);

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

And it’s backwards-compatible, so no actual hurt in case you proceed to make use of the “previous” method. It’s not like substring selectors don’t produce other use circumstances and develop into completely out of date. However possibly that’s it: this isn’t an “improve” of one thing we have already got, however a brand new factor that isn’t progressive enhancement out of the gate. We’d need to @help it till it turns into a Baseline characteristic:

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

…which can or will not be a protracted wait. However we don’t know. And if ergonomics are the promoting level, then we’re dropping that within the wait.

Also needs to be aware that the wildcard doesn’t match different circumstances or non-dashed circumstances:

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

One other worthy be aware is that the spec presently implies (however doesn’t explicitly state) that this has the identical specificity as a category selector, (0,1,0). That’d make sense, as .prefix-* is absolutely no completely different than writing .prefix-variation.

That stated, I like the way it would possibly probably look in a nested syntax:

.prefix {
  /* This is able to work, proper? */
  &-* { /* ... */ }
}

…and Dave’s plea to help deciding on net elements: