Resolved: CSS Class Prefix Selector

Simply what Bramus shared the opposite day:

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

/* Itemizing all the pieces... 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, when 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 protecting 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 put up, 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 Degree 5 spec draft. So, chances are high that we’ll see it formally adopted sooner or later and carried out 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 concept. I can’t fairly put my finger on it. Maybe it’s redundancy as in, we will already do that with current selectors? Bramus cites efficiency points with current substring selectors as a major motive we want this. However Brian Kardell’s reply resonates with me:

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

/* outdated */
colour: hsla(100, 50%, 50%, .5);

/* new */
colour: hsl(100 50 50% / .5);

And it’s backwards-compatible, so no actual hurt when you proceed to make use of the “outdated” method. It’s not like substring selectors don’t produce other use instances and turn out to be 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 function:

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

…which can or might 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.

Must also word that the wildcard doesn’t match different situations or non-dashed instances:

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

One other worthy word is that the spec at the moment 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 de facto no totally different than writing .prefix-variation.

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

.prefix {
  /* This may work, proper? */
  &-* { /* ... */ }
}

…and Dave’s plea to help choosing internet parts: