Style queries are changing how we think about responsive design by letting CSS react to a container’s style state, not just its size. Instead of only using viewport-based media queries, authors can declare @container style(…) rules that conditionally apply styles to descendants when a container’s computed style values match specified conditions.
This article walks through what style queries are, how they work today, where they’re supported, common use cases, and practical migration tips. It draws on the CSS Conditional Rules / Container Queries editor’s draft, recent browser rollout notes (Chromium and WebKit), Can I Use tracking, community surveys, and implementation guidance from vendor documentation and web-platform-tests.
What are style queries?
At a formal level, style (container) queries are @container conditions that test a container’s computed style values using the style functional notation. They are part of the container-query features described in the CSS Conditional/Containment specs and allow rules to apply to descendants when a container’s styles match.
The authoritative spec material lives in the W3C CSS Conditional Rules / Container Queries (CSSWG Editor’s Draft), which documents the @container style(…) syntax, its semantics, and how style queries interact with size and scroll-state queries. The spec also defines a grammar and outlines how comparisons and ranges should work as the feature evolves.
Practically speaking, the most useful input for style queries today is CSS custom properties: example usage looks like @container style(--theme: dark) { / styles for descendants when the container’s --theme is "dark" / }. This lets you toggle component states from markup or JS by changing custom properties instead of toggling classes.
Syntax, limits, and what style queries accept
The current spec describes style queries using the @container style(...) notation and defines to accept declarations, property names and custom-property tokens. The plan includes style-range comparisons and numeric range operators for richer checks in the future.
However, implementations are conservative. Most engines today only support exact-value checks against custom properties (for example, @container style(--mode: compact)). Range comparisons and numeric operators are being added to some engines (see Blink/Chromium work), but are not yet universally supported.
Because matching computed values can be tricky, the spec and platform docs warn that you should register properties (with @property) when comparisons require parsed values (like colors or numbers). Also avoid querying and applying the same property to the same element in one rule, which can create infinite re-evaluation loops.
Behavioral model and the important default: all elements are style containers
One key behavioral rule that reshapes the mental model: unlike size container queries (which require an explicit container-type), style queries treat all elements as style containers by default. That means you can check a parent’s custom property without adding a containment declaration.
This default makes parent-style checks convenient because you don’t need to opt into container behavior for every component. At the same time, it changes how authors think about scope: style state can be inherited and matched broadly unless you explicitly opt an element out or scope your selectors tightly.
Because of the broad applicability, the community recommends scoping queries to small subtrees to reduce re-evaluation costs and unpredictability. Opt-out patterns and containment APIs remain relevant when you need strict isolation to avoid layout churn.
Browser support and rollout (Jan 2026 snapshot)
Container size queries are now broadly available across modern browsers, but container style queries are at a more mixed stage. Chromium-based browsers (Chrome, Edge) support custom-property style queries; initial partial support shipped around Chrome 111 and has expanded through 2025 and 2026 releases.
WebKit has landed related work and you can find style-query behavior in Safari tech previews and Safari 18+ lineage builds, although support has been somewhat fragmented across releases. Firefox has delayed baseline enablement and has an open blocking bug; as of late 2024/2025 Firefox withheld baseline availability of style-query features.
Can I Use and browser-vendor release notes track this granularly: separate entries exist for container size queries, style queries (custom-property checks), and expanded features like range-syntax. Check compatibility tables before depending on style queries in public-facing sites and provide fallbacks when Firefox reachability matters for your audience.
Practical use cases, examples, and demos
Publishers and browser teams have published representative demos: component-level theming using custom properties, weather-card examples that toggle a theme flag on a card, and feature-flag styling via --feature toggles. These show how components can adapt to placement instead of the viewport.
Common patterns include component-scoped theming, feature flagging without JS toggles, and internal layout adaptations that would previously require JavaScript. Vendors’ docs (Google/Chromium tutorials) demonstrate scoping selectors to limit DOM cost and show how to use @container style(--theme: dark) for isolated theming.
Community adoption is growing but still limited. The State of CSS surveys reported around ~5.4% usage of @container style queries in 2024; awareness is higher but real-world usage lagged behind size queries. That gap reflects browser parity concerns, learning containment APIs, and caution around performance implications.
Performance, invalidation, and best-practice warnings
The spec requires implementers to deliver container-query evaluation changes as style-change events and to optimize invalidation so the whole document isn’t recomputed for every change. Browsers include tests and optimizations to avoid layout churn when container styles change, but authors must still be careful.
Rules of thumb: scope style queries narrowly, avoid querying and updating the same property on the same element in the same rule, and prefer updating a container’s custom property at discrete times rather than animating it without care. Registered @property descriptors are important when you need accurate comparisons for parsed types.
Performance guidance from community write-ups and vendor docs also recommends limiting selector scope, testing reflow costs, and following containment patterns to reduce propagation. If you misapply style queries broadly, you can incur significant re-evaluation costs across the subtree.
Tooling, frameworks, and testing strategy
DevTools support is improving: Chrome DevTools shows @container rules in the Styles pane and can reveal the container that caused a match, which is invaluable for debugging. Other browsers are catching up but tooling parity is incomplete.
Frameworks and tooling are adapting: Tailwind v4 added native container-query variants, and many design systems and component libraries are experimenting with container-aware utilities. This ecosystem movement signals rising practical adoption in component-driven workflows.
For production readiness, use feature-detection (@supports) or a progressive-enhancement strategy, and keep media-query fallbacks for critical layout changes. Web-platform-tests exist for many container-style behaviors, use them if you are implementing polyfills or writing tests for conformance.
Migration guidance: when to use media queries vs container style queries
Pattern guidance from authors and browser teams is consistent: use media queries for page-level breakpoints (viewport-driven layout) and container queries, especially style queries, when you want components to adapt to their container or local state. Container-first components are more reusable and placement-agnostic.
Practical migration steps: audit which responsive rules depend solely on viewport, move component-scoped adaptations to container queries, adopt container units and container-aware utilities, and test across targeted browser versions. Keep a compatibility matrix (Can I Use, State of CSS) to decide when to flip defaults in your codebase.
Finally, add fallbacks for browsers that lack style-query support (notably older Firefox versions). Common strategies include CSS-only fallbacks, small JS polyfills for critical features, or graceful degradation where the component still works but with less adaptive finesse.
Style queries let CSS react to container “style state” rather than just geometry. They enable component-scoped, declarative theming and feature-flagging with less JavaScript and a tighter declarative surface for responsive components.
Adopt them gradually where Chromium/WebKit support is sufficient for your audience, follow containment and performance guidance, and feature-detect or provide fallbacks for broader reach. The one-line takeaway: style queries are powerful and increasingly supported, but check compatibility and design defensively.