A class prefix selector is now spec text in Selectors Level 5

The draft of August 18 adds section 2.1, Class Prefix Selectors, defining .foo-* to match any class beginning with that prefix. It replaces the attribute-selector workarounds every design system carries. Nothing implements it yet, and the matching rule has an edge that will catch people: .foo-* does not match foo--bar.

If you maintain a utility-class system you have written [class^="btn-"] and [class*=" btn-"] side by side, once for the first class in the attribute and once for the rest, and you have explained the pair to someone at least twice. The Selectors Level 5 editor's draft of August 18, 2026 now defines the thing that replaces both. What the spec text says Section 2.1 defines a class prefix selector as a full stop, immediately followed by an identifier that ends in one or more hyphens, immediately followed by an asterisk. .foo-* is the canonical example. It represents an element that would match a class selector starting with the given prefix. Two conditions come with it, and the second is the one worth remembering. The class has to carry at least one character beyond the prefix, so .foo-* does not match a bare foo- . And the first character after the prefix must not be a hyphen, so .foo-* does not match foo--bar either. If your naming convention uses a double hyphen for modifiers, as BEM does, that rule decides whether this selector is useful to you or not. Why it exists The proposal came from Lea Verou in 2024 and the argument for it was never about capability. Both existing forms already work. They are simply verbose, they read badly, and the two-part pattern exists only because an attribute substring match has no concept of a word boundary in the class list. A selector that knows it is matching classes does not need the pair. That is the whole feature: the same match, expressed once, in a form that says what it means. What this is not This is spec text in an editor's draft, which is a real step and not a shipping date. No browser implements it, there is no Baseline status to check, and an editor's draft can still change before it reaches Candidate Recommendation. The practical consequence today is planning, not code. If you are about to standardize a naming convention across a design system, it is worth knowing that a selector which understands prefixes is coming and that it will treat a double hyphen as a non-match. When it does arrive, @supports selector(.foo-*) is the gate to put it behind.