Style Queries Are More Flexible Than You Think

Container style queries are still an early-stage feature — defined in the CSS Containment Module Level 3 spec (currently an Editor’s Draft) with a few open discussions still underway. But the core mechanics are taking shape, and they offer more nuance than the simple conditional styling examples often shown.

Every Element Is Already a Style Container

You don’t need to declare a container-name or container-type to create a style container. Everything is one by default. A common example: removing italics from <em>, <i>, and <q> when they appear inside already-italicized content. That query works without any explicit container setup because the browser falls back to the nearest relative — typically the direct parent of the element receiving the styles.

This implicit behavior is possible because style-based queries don’t have the same constraints as dimensional queries. Dimensional queries like size and inline-size require CSS containment on size, layout, and style to prevent layout loops — an invasive constraint that needs careful author control. Style queries have no such requirement. Since descendant styles can’t affect the computed styles of an ancestor, no containment is needed, and there are no unexpected side effects in making every element a style query container.

When a style query runs:

  • If a container is found, conditions resolve against it.
  • If multiple containers match, the nearest relative wins.
  • If no match exists, unknown is returned.

Dimensional and Style Queries Can Coexist

Because every element is a style container regardless of container-type, you can set an explicit container-type for dimensional queries and still implicitly query styles on the same element without an explicit container-name. The style query uses the nearest match; the dimensional query uses the declared containment.

That means a single container can support both query types:

/* Container supports both style and dimensional queries */
.card {
  container-type: inline-size;
}

Excluding Containers and Controlling Matches

If you want an element excluded from participating in the style query matching process, you could set container-type: none on it — although this isn’t a perfect solution, since it also removes the element from dimensional query matching.

For more control, explicit style query containers are useful when debugging which container gets queried. Some properties, like padding, aren’t inherited, so there’s no reliable way to predict the best matching container without an explicit name. In those cases, using container-name tells the browser exactly which containers to draw from. You can even assign multiple names to a single container — they’re optional, reusable, and can help the browser find a match in more scenarios.

Combining Queries and Toggling Styles

Style queries support the and and or operators for combining conditions:

/* Query matches if the container has both properties set */
@container style(--theme: dark) and style(--accent: blue) {
  /* styles */
}

There’s overlap with the proposed toggle() function for cycling between values like italic and normal. For binary swaps, toggle() might be simpler. But style queries handle more complex cases better: they aren’t limited to toggling single properties and can express richer conditional logic. Miriam Suzanne identifies three scenarios where style queries beat toggle(): when toggling many properties at once, when conditions depend on more than one value, and when the fallback behavior needs more nuance.

Beyond Simple Styling

Style queries also offer a formal solution to the “CSS custom property toggle trick,” where empty custom properties and comma-separated fallbacks simulate toggling. Style queries make that pattern unnecessary.

For generated content, style queries on ::before and ::after resolve against the element that generates the content. Web components work too — you can set a container-name and container-type on the :host pseudo-element, then have internal elements query the host’s attributes or computed styles.

Where Things Stand

These details come from Miriam Suzanne’s public explainer notes, not the official spec — but they signal where discussions are heading. Open questions worth following include whether style() queries should allow the !important flag, whether style queries of standard properties should move to Level 4, and how higher-level custom properties that control multiple declarations might work.