Chrome 158, now in beta, ships ::highlight(*) — a zero-specificity universal selector that lets you style every CSS Custom Highlight with one rule instead of repeating declarations per name.
Chrome 158 entered beta on October 28, 2026, and tucked into its CSS additions is a small but overdue fix for anyone building with the CSS Custom Highlight API: ::highlight(*), a universal selector that matches every registered highlight regardless of name. The underlying spec change landed in CSS Pseudo-Elements on September 30, and Blink's API owners signed off on the implementation on October 20 — so this has moved from proposal to shipping browser feature in under a month. For teams whose custom software engineering work includes in-browser text annotation, search-result highlighting, or collaborative editing UI, this closes a gap that's been awkward to work around since the API first appeared.
Per the Chrome Platform Status release notes, ::highlight(*) matches the highlight pseudo-elements of every custom highlight registered via CSS.highlights, regardless of the name used to register it. Its argument contributes zero specificity, which is the detail that makes it useful rather than just a shortcut: a rule written as ::highlight(*) { background: yellow; } acts as a fallback base style, and any later rule naming a specific highlight — ::highlight(search-match) { background: orange; } — wins the cascade regardless of source order. Coverage from daily.dev's rundown of the spec change confirms the same timeline: merged into CSS Pseudos on September 30, approved by Blink API owners on October 20, shipping in Chrome 158.
Before this, if your page registered a dozen named highlights — search matches, spell-check flags, collaborative-editing cursors, redaction markers — and wanted them to share a base font-weight or padding, you repeated that declaration a dozen times, once per ::highlight(name) rule. Any shared property you forgot to repeat silently fell back to no styling at all rather than inheriting anything sensible.
The CSS Custom Highlight API itself is still relatively young — it lets JavaScript register arbitrary text ranges as named highlights without touching the DOM, which is exactly what you want for find-in-page matches, spell-check underlines, or live-collaboration cursors layered over read-only content. But the spec initially only defined per-name selectors. That works fine when you have one or two highlight types; it gets repetitive fast once a real application — a code editor with syntax flags, a document reviewer with multiple reviewer colors, a search UI with match-and-near-match states — is juggling five or more highlight categories that all need the same baseline treatment.
::highlight(*), then override only what differs in the named rules.::highlight(*) rule never beats a named highlight rule on specificity grounds, so you can register it anywhere in your stylesheet without worrying about source-order fights.@supports selector(::highlight(*)) if you need the fallback behavior today, and keep your per-name rules as the safety net.Chrome 158 reached the beta channel on October 28, 2026, with stable release scheduled for November 17, 2026 according to Chrome Platform Status. That means ::highlight(*) is testable today behind Chrome's beta channel but not yet something to depend on in production without a fallback. No origin trial or flag is required — once Chrome 158 reaches stable, the selector is simply available. Firefox and Safari have not published a position on the universal highlight selector yet, so treat this as Chromium-only for the immediate future, same as the rest of the Custom Highlight API's early support story.
If your product already uses named ::highlight() rules and you've been copy-pasting a shared block of declarations across them, this is worth a short refactor once Chrome 158 ships to stable — not urgent, but a clean win with no behavioral risk given the zero-specificity guarantee.