Firefox 157 went stable on September 29, 2026, and buried in its release notes is a fix for a gap that's quietly annoyed anyone writing defensive CSS for at-rules: until now, @supports could test whether a browser understands a property or selector, but had no direct way to ask whether it understands an entire at-rule like @scope or @container. The new at-rule() function closes that gap, and Safari Technology Preview shipped the same capability weeks earlier — a rare case of two engines converging on identical syntax before the feature has even reached Baseline. For teams doing standards-based frontend engineering, it's a small addition that removes a real source of fragile feature-detection hacks.
The function slots into two existing places. Inside a stylesheet, you write:
@supports at-rule(@scope) {
/* styles that rely on @scope being understood */
}And when conditionally loading a separate stylesheet, the same check works in the supports() function of @import:
@import url("scoped-theme.css") supports(at-rule(@scope));Either way, the test is binary and specific: does this engine parse and act on the named at-rule at all? That's different from testing a property inside it, and the difference matters more than it sounds.
Before at-rule(), the closest thing to detecting support for a newer at-rule was testing some property or value that only made sense inside it — which works until the at-rule gains an unrelated feature a browser hasn't shipped yet, or until the property you picked turns out to be supported on its own outside that context. Either way, the test silently lies. An at-rule itself isn't a property or a selector, so @supports had no vocabulary for asking about it directly; at-rule() gives CSS that vocabulary instead of asking developers to find an indirect proxy and hope it stays accurate.
Safari Technology Preview 251 shipped @supports at-rule(...) on August 26, 2026, over a month before Firefox 157 stabilized the matching syntax on September 29. Having WebKit and Gecko land the identical function shape ahead of a stable release in either browser is unusual — most CSS features drift through slightly different experimental syntax before converging. Chrome has not shipped the equivalent as of this writing, so the feature currently covers two of three major engines in some form, one of them still in preview.
If you maintain a design system that progressively adopts newer at-rules — @scope for style containment, @container for component-level responsiveness, @layer for cascade ordering — at-rule() is the cleanest way to gate that adoption without shipping broken styles to browsers that don't understand the wrapper. It's also useful defensively in the other direction: loading a lighter fallback stylesheet via @import supports() when an engine can't parse the at-rule your primary sheet depends on, instead of letting unsupported rules fail silently mid-cascade.
Firefox 157 is stable now; Safari's support is still at the Technology Preview stage, so it isn't in a shipped Safari release yet. With Chrome absent from the list so far, treat at-rule() itself as something to detect — ironically — with a plain capability check in JavaScript (CSS.supports('at-rule(@scope)')) before relying on it inside a stylesheet meant to run everywhere today. Track the feature's entry on MDN and in the CSS Conditional Rules Level 5 spec for Chrome's status before building a dependency on it.