Feature Queries (@supports)

Feature Queries let you write CSS that only applies when a browser supports a specific property. Site Designer’s Feature Queries panel gives you a visual interface to create and manage @supports rules without writing them by hand.

What are Feature Queries?

A CSS @supports rule is a conditional block that checks whether a browser understands a given CSS property before applying the styles inside it. This technique is the backbone of progressive enhancement — newer browsers get the best experience, and older browsers get a functional fallback.

A basic @supports rule looks like this:

css
@supports (display: grid) { .layout { display: grid; grid-template-columns: repeat(3, 1fr); } } /* Browsers that don't support grid see this instead */ .layout { display: flex; flex-wrap: wrap; }

The browser reads the @supports block only if it recognizes display: grid. Older browsers that don’t understand @supports at all skip the entire block safely.

Common use cases

Feature to checkWhy it matters
(display: grid)Provide a Flexbox fallback for very old browsers
(display: flex)Provide a float-based fallback for legacy IE
(backdrop-filter: blur(1px))Safari needed a -webkit- prefix until 2022
(gap: 1rem)gap in Flexbox was added later than in Grid
(aspect-ratio: 1)Older browsers need a padding-top hack instead
(container-type: inline-size)Container Queries are still not universal

The Feature Queries panel in Site Designer

Open the Feature Queries panel by clicking the @supports icon in the left toolbar. The panel shows all @supports rules defined in the current project.

Each rule displays:

  • The condition being tested (e.g., display: grid)
  • Whether the condition uses a not negation (for writing styles that apply when a feature is absent)
  • A list of CSS declarations that apply when the condition is true

Adding a @supports rule

  1. Click + Add Rule in the Feature Queries panel.
  2. Enter the CSS property and value you want to test in the Condition field (e.g., display: grid).
  3. Toggle the Negate switch to wrap the condition in not if you want styles that only apply when the feature is not supported.
  4. In the CSS block editor, write the declarations to apply when the condition is met.
  5. Click Save. Site Designer adds the rule to your project CSS above the standard rules it would otherwise override.

Editing fallback CSS

The most reliable pattern is to write the fallback styles first (outside any @supports block) and then override them inside @supports. Site Designer follows this order automatically when it writes the exported CSS:

  1. Base/fallback styles (Flexbox layout, etc.)
  2. @supports (display: grid) { ... } enhancement on top

This ensures older browsers that ignore @supports still see valid styles.

Example: Grid with Flexbox fallback

The following pattern gives browsers with Grid a two-dimensional layout while Flexbox-capable browsers (but no Grid) still get a usable row-based layout:

css
/* Fallback: flex row wrapping */ .card-grid { display: flex; flex-wrap: wrap; gap: 1rem; } .card-grid .card { flex: 1 1 300px; } /* Enhancement: proper grid when supported */ @supports (display: grid) { .card-grid { display: grid; grid-template-columns: repeat(auto-fill, minmax(300px, 1fr)); } .card-grid .card { flex: unset; } }