[selectors] New selector to facilitate utility classes (`[name~^=value]`? `.prefix-*`?)

[LeaVerou]

(I’d be surprised if this has not been proposed before, but I was not able to find anything)

Pain point

It is very very common to use classes with a shared prefix as to specify key-value pairs. For example:

• The HTML spec recommends using this pattern, to specify the language of <code> elements (and it has been a huge pain to handle in Prism).
• Tailwind, Bootstrap and other frameworks use classes like pt-6 or space-y-4 to specify their styles
• Icon families like FontAwesome and Bootstrap Icons use utility classes like fa-* / bi-* respectively to specify their icons (in this case the prefix does double duty: it serves as both the key and a namespace).
• Authors often create such utility classes of their own.

These utility classes have commonalities shared across all instances, as well as declarations that are specific to the value used. Usually, these are implemented in one of three ways:

1. Enumeration of all the possibilities in the CSS, when they are finite. Manually (and painfully) when they are few, with build tools when they are dozens. This includes both CSS rules for the specific values of each utility class, as well as exceedingly long selector lists for the commonalities among them.
2. Pushing the friction to authors by asking them to use one class for the commonalities and one for the specific values. E.g. to use a Bootstrap Icons icon, authors need to use both a bi class and a bi-iconname class.
3. This is not an option for libraries, but authors (who have more control of their markup) may do things like [class^="prefix-"], [class*=" prefix-"]

None of these are ideal. It seems pretty straightforward to provide the capability these use cases really need, so this seems like a a quick win.

While the vast majority of use cases are around class names, I could see something like this being useful for all attributes that take a space-separated list of values.

Potential solutions

I see two options:

1. Extending class selectors to support wildcards. It appears that .foo-* is actually not currently valid, so it seems like a natural choice, especially as it extends nicely to other types of wildcard selectors such as element names, attribute names, ids, etc.
2. Introducing a new attribute selector, that is basically a combination of ~= and ^=. Options for the operator could be ~^=, ^~=, or even ^~ if we want to keep it to a max of 2 characters. This is quicker to implement, but very specific to attribute selectors, and far less intuitive.

[bkardell]

If I understand you are saying that libraries cant do *= because the amount of fuzziness there may have many too potential false positive matches, but the selectors you're suggesting would instead allow fuzzy matching to at least be on the individual dom tokens? If so, I do like that... I may be biased in that I like improving our regexp powers in CSS selectors all around.

[Loirooriol]

It appears that .foo-* is actually not currently valid, so it seems like a natural choice.

I think that can be confusing because * looks like the universal selector (analogous to #6571 (comment)).

Introducing a new attribute selector, that is basically a combination of ~= and ^=

I would go this way. I imagine a combination of ~= and $= could also be useful (but less frequently).

[romainmenke]

I am strongly in favor of more powerful tools for attribute selectors but I do wonder if the use case is valid.

Encoding a lot of key/value pairs in class names seems like the wrong approach.
Is there a reason that frameworks like Tailwind, Bootstrap do not use attributes?

Maybe because attributes are supposed to have a data- prefix, whereas classes are always user defined. The data- prefix makes them much more verbose.

pt-6 -> [data-pt~="6"]
<div class="pt-6"> => <div data-pt="6">

Styling the commonalities then becomes trivial with [data-pt]

[Crissov]

There is #1010, but that is about regular expressions and element selectors, not simpler wildcard class selectors, which were also not covered in #354.

For what it’s worth, I believe utility classes for atomic design tokens – i.e. usually with a name that roughly matches its single style rule like .font-sm {font-size: 0.8rem} – are very much an anti-pattern for production-level CSS. They should be a tool for early-stage development only, which are then grouped into patterns. However, I’m probably in the minority with that view nowadays.

That is partially why I suggested, in #3714, to introduce something like this:

$fg-green {color: var(--my-green);}
$bg-white {background: white;}

which could then be applied verbosely in HTML as

<a style="@include $fg-green $bg-white">dev</a>

and if that is found to establish a common pattern, it would be moved back to CSS:

.pattern {@include $fg-green $bg-white;}

and the HTML could become more readable and semantic again.

<a class="pattern">prod</a>

Applied to one of the initial examples:

$bi {/*commonalities*/}
.bi-iconname {
  @include $bi;
  --icon: url(icons.svg#name);
}

instead of the now suggested

.bi-* {/*commonalities*/}
.bi-iconname {
  --icon: url(icons.svg#name);
}

[xiaochengh]

@Crissov This looks like custom mixins (#9350)

So IIUC wildcard class selectors and custom mixins are basically solving the same problem.

I'm also wondering if a selector that targets a group of class names / attribute names will make implementations significantly more complicated. For example, Blink maintains maps keyed by class names for efficient style matching and invalidation, and it will be much more complicated if we have to eg put a trie there for prefix matching.

Mixins solve the same use cases without affecting style matching and invalidation. So +1 to mixins over wildcard selectors.

[LeaVerou]

@romainmenke

I am strongly in favor of more powerful tools for attribute selectors but I do wonder if the use case is valid.

Encoding a lot of key/value pairs in class names seems like the wrong approach. Is there a reason that frameworks like Tailwind, Bootstrap do not use attributes?

Maybe because attributes are supposed to have a data- prefix, whereas classes are always user defined. The data- prefix makes them much more verbose.

pt-6 -> [data-pt~="6"] <div class="pt-6"> => <div data-pt="6">

Styling the commonalities then becomes trivial with [data-pt]

I cannot speak on behalf of every author, but I suspect the reasons are multi-fold:

1. For certain things, classes feel more semantically appropriate. Basically, ask yourself why would you use classes over data- attributes (providing a value is not the only reason, since you can have boolean attributes!). The exact same reasons apply to these use cases. These are not just key-value pairs, they are opting in to a certain style AND parameterizing it.
2. Verbosity, yes. Using a data- attribute is 6 extra characters. For something as short as pt-6, that's 175% (!) more reading & typing.
3. In some cases the parameterization even evolves from a single class name. E.g. columns, with later variants columns-3, columns-4 etc.

The fact that authors are willing to go through the pain of currently using this pattern instead of using data- attributes where they could get this for free is a testament to how important this is to them. So the answer cannot just be you’re doing it wrong.

That said, being able to target attributes based on a prefix of their name is also needed, though less frequently.

@Crissov
For some of these use cases, the weight of having to specify the mixin on all of these would produce far more code than having a separate base class.
Consider e.g. Bootstrap Icons. They have over 2000 icons. The mixin approach would add 2000 * 13 = 26,000 characters to their CSS code. In contrast, their base .bi class is 4 declarations… And Font Awesome has even more icons…

[Crissov]

@xiaochengh, like I said there, it’s mostly a syntax choice (disregarding benefits for JS).

To really improve the icon use case, you’d probably want something like this instead:

.iconname {
  --icon: src(concat("icons.svg#", selector(classname)));
}

[LeaVerou]

@Crissov having a function to get the part after the class name and string concatenation are both very useful in their own right, but without a way to target elements with a given class prefix where would you apply this? In your code example you use .iconname as the selector, does that mean you envision 2000+ CSS rules repeating the same thing? Or a 2000 selector-long selector list? Or making it a library user problem and continuing to ask users to manage two classes?

[Crissov]

I’d expect a very long list of selectors. Also, attr(class) or something like list(1 from attr(class)) seems more feasible than selector().

Anyway, that’s sidetracking from the original issue, so I should probably raise a new one.

[xiaochengh]

Consider e.g. Bootstrap Icons. They have over 2000 icons. The mixin approach would add 2000 * 13 = 26,000 characters to their CSS code. In contrast, their base .bi class is 4 declarations… And Font Awesome has even more icons…

That's a good argument. I take my opposition back.

This is like an inheritance vs. composition debate. Normally I prefer composition, but in CSS verbosity is a much bigger concern, as more code means more network usage.

[LeaVerou]

In terms of syntax, I just had a discussion with @fantasai about how we actually need to be able to target prefixes across several types of selectors, not just classes:

• element selectors, as WC libraries often define multiple elements whose tag names share the same prefix
• attribute presence, for the same reason

Therefore, I think using a wildcard, despite its unfortunate similarity with the universal selector, is the way to go here.

[romainmenke]

I think we need to consider other options than the wildcard for elements, classes,
Maybe even a functional notation. e.g. :has-prefix(.foo-)

I am concerned about a couple of things:

• searching for * is not easy, you have to already know the name in context (universal, wildcard) to be able to find more information.
• reading and understanding code becomes harder when the density of ascii symbols is greater
• people new to CSS will have a hard time learning the difference between this and the universal selector
• there are a lot of tools that assume that the order in a compound doesn't matter
• there are a lot of tools that assume that the universal selector must always be the first part in a compound

I think that having the absolute shortest notation for the selector isn't that critical here. If possible without too much friction I think we should pursue this.

[Loirooriol]

I'm not convinced.

element selectors

Perfectly covered by :tag() from #6571 (comment)

attribute presence

We could add something for this, e.g.

:attr(^= foo-) /* Matches if there is an attribute whose name starts with foo- */
:attr(^= foo-, ^= bar-) /* Matches if there is an attribute whose name starts with foo-
                           and whose value starts with bar- */

By using * we lose the ability to customize the matching, e.g. specifying case sensitivity.