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.
Source
Selectors Level 5, 2.1 Class Prefix SelectorsCSS Working Group drafts · Original published August 18, 2026
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.
Sources
Related
Safari 27.0 ships an MCP server, so a coding agent can drive the browser itself
WebKit published the feature list on September 17, 2026, and it is the longest the team has written: 83 features, up from 58 at the first beta in June, and 844 quality fixes against the 525 announced at WWDC. The headline for anyone who builds with a coding agent is the Safari MCP server, which hands the agent the DOM, network requests, screenshots and console output from a real Safari window. Customizable Select turns the real select element into something you can fully restyle, and scroll anchoring stops the page from jumping when content loads in above what you are reading.
WebKit Blogverified
Safari Technology Preview 252 adds named-feature() and lets SVG reach a filter in another file
The preview build came out on September 11, 2026 and covers WebKit changes between 319252@main and 320112@main. Eleven features are new, and two of them extend the same job: how a stylesheet, and then a script, finds out what the engine underneath can do. The named-feature() function asks about a behavior that has no syntax of its own, and the registry behind it holds exactly two entries today. SVG also gained external resources, so the url() reference can finally point at a filter, mask or gradient stored in another document.
WebKitverified
Interop 2027 proposals close on September 23, and untested ideas do not qualify
The call for Interop 2027 Focus Area proposals opened on September 3, 2026 and closes on September 23, 2026. Proposals are filed as issues on the web-platform-tests/interop repository, and two conditions decide almost everything: the technology must already have a mature standard, and it must be testable, because the test results are what the dashboard scores. Anything that fails the second condition is steered toward an Interop Investigation instead. Twenty days is the whole window, and the evidence a good proposal needs takes longer than an evening to assemble.
WebKitverified