Style Queries

The plain-language idea

The container-queries lesson covered container-type: inline-size and @container (min-width: ...) — a component reacting to how much space its container gives it. Style queries reuse that exact same container-query machinery to ask a different kind of question: not "how big is my container," but "what value does a specific CSS custom property hold on my container, right now."

The syntax is `@container style(--property: value) { ... }`. Instead of a size condition inside the parentheses, it's a custom-property condition. If some ancestor has container-type set (the same setup container queries already need) and that ancestor — or the element carrying the style query itself — has --theme: dark set on it, then `@container style(--theme: dark) { ... }` matches, and the enclosed rules apply.

What that unlocks: a component can adapt to a "mode" — theme, density, variant, whatever an ancestor expresses through a custom property — without any JavaScript reading or writing a class name or data- attribute to signal that mode. The custom property itself is the signal, and CSS reacts to it directly.

See it in a real thing: a card that adapts to a theme flag set higher up the tree

.theme-scope {
  container-type: inline-size;
  --theme: light;
}

.theme-scope.is-dark {
  --theme: dark;
}

.card {
  background: white;
  color: black;
}

@container style(--theme: dark) {
  .card {
    background: #1a1a1a;
    color: white;
  }
}

Nothing here reads --theme in JavaScript, and no code toggles a .card--dark class on the card itself. Some ancestor sets --theme: dark (however that gets decided — a class toggle further up, a media query, anything), and the @container style(...) block reacts to that value directly, the same way a size-based @container block reacts to a width crossing a threshold. It's worth being explicit about where this sits relative to the rest of the track: :has() lets an element react to what's inside or next to it; size container queries let it react to how much space it has; style queries let it react to an ancestor's custom-property state — three different signals, evaluated natively by CSS instead of JavaScript, for three different questions.

What people usually miss

Watch out

• Style queries currently only reliably test custom properties, not arbitrary standard CSS properties. `@container style(--theme: dark)` is the supported shape; querying a built-in property's computed value (`style(color: red)`) is part of the broader spec ambition but isn't the part that's actually usable yet — stick to custom properties.
• This is genuinely the least mature feature in this track. Where size-based container queries are safe as a primary layout tool, style queries are still settling — the right frame for an interview or a real project right now is "I know the problem this solves and the syntax that solves it," not "I've shipped this as load-bearing production UI."
• A style query still needs a container. The same container-type setup that size queries require applies here too — style queries are an alternate condition inside the same @container mechanism, not a separate feature with its own setup step.
• It replaces a specific JS pattern: reading an ancestor's custom property and toggling a class to mirror it. It's not a general replacement for data- attributes or class-based theming — those remain perfectly reasonable, especially while style-query support is still catching up.

Why this matters in interviews

"Container queries react to size — what if I need a component to react to something else about its container, like a theme flag?" is a question aimed at whether a candidate knows the container-query mechanism generalizes beyond size at all — naming style queries and being honest about their support maturity is a stronger answer than either not knowing they exist or overselling them as production-ready.