@supports CSS At-Rule

The @supports at-rule is a feature-query mechanism: it lets an author conditionally include blocks of CSS only when the user agent recognizes and implements the specified CSS feature(s). Its primary purpose is progressive enhancement and graceful degradation — authors can declare modern, capability‑dependent rules inside the block and keep simpler fallbacks outside it so that browsers that don’t understand a feature ignore the enhanced rules while still applying the fallback styles. Conceptually it answers the question “does this browser know how to handle this feature?” and uses that answer to enable or disable whole rule sets.

When the user agent processes a stylesheet, the condition in the @supports block is evaluated and the block’s contents are either treated as if present in the cascade or ignored. This means that selectors and declarations inside the block participate in the cascade, inheritance, and specificity rules exactly like normal rules when the condition is met; when it is not, those rules simply do not exist for the cascade. Because the at-rule gates whole rule sets rather than altering specificity, it’s important to place fallback declarations outside the block if you want them to apply in older or feature-limited environments.

Authors commonly use @supports to encapsulate modern layout techniques, new properties, or optimizations so they don’t interfere with baseline styling. It often appears alongside other conditional mechanisms — for example, used in coordination with responsive queries or scoped to component styles — to build robust, adaptive interfaces. Since the block is evaluated by the rendering engine, it also serves as a safer alternative to user‑agent tests or script-based sniffing: you explicitly check for feature recognition rather than inferring it from the agent or platform.

There are practical limits and gotchas to keep in mind. The at-rule tests whether a browser recognizes a feature, not whether that feature will necessarily behave as you expect in every layout context, so it’s not a substitute for runtime behavioral testing. It is not intended for detecting non‑CSS capabilities (for example, JavaScript APIs) or for testing complex runtime interactions that depend on content or environment beyond the feature set. Finally, because rules inside a feature-query are either entirely applied or ignored, plan your cascade so that fallbacks remain effective: put baseline styles outside the block and reserve experimental/optimized rules for inside it.

@supports  {
  /* specific rules */
}

• notThe not operator can precede any expression to create a new expression, resulting in the negation of the original one. The following example returns true if the browser's transform-origin property doesn't consider 10em 10em 10em valid:

  @supports not (transform-origin: 10em 10em 10em) {}

• andThe and operator creates a new expression from the conjunction of two shorter expressions. It returns true only if both of the shorter expressions are also true. The following example returns true if and only if the two shorter expressions are simultaneously true:

  @supports (display: table-cell) and (display: list-item) {}

• orThe or operator creates a new expression from the disjunction of two shorter expressions. It returns true if one or both of the shorter expressions is also true. The following example returns true if at least one of the two shorter expressions is true:

  @supports (transform-style: preserve) or (-moz-transform-style: preserve) {}

The following information will show you the current browser support for the CSS at-rule @supports. Hover over a browser icon to see the version that first introduced support for this CSS at-rule.

This at-rule is supported by all modern browsers.

Desktop

Tablets & Mobile