Feature Queries with @supports in CSS

Introduction

CSS keeps adding new features.

Modern CSS includes tools such as:

1display: grid;2aspect-ratio: 16 / 9;3container-type: inline-size;4backdrop-filter: blur(10px);

These features can be useful, but not every browser always supports every CSS feature.

A feature query lets you ask the browser:

1Do you support this CSS feature?

If the browser supports it, the browser applies the CSS inside the feature query.

If the browser does not support it, the browser ignores that CSS block.

Feature queries use the @supports at-rule.

Example:

1@supports (display: grid) {2  .layout {3    display: grid;4  }5}

This means:

1If the browser supports display: grid, apply these styles.

Feature queries are useful when you want to use modern CSS safely.

They help you write fallback styles first, then add enhanced styles only when the browser supports them.

What Is @supports?

@supports is a CSS at-rule.

It checks whether the browser supports a CSS declaration.

A basic feature query looks like this:

1@supports (property: value) {2  selector {3    property: value;4  }5}

Example:

1@supports (display: flex) {2  .nav {3    display: flex;4    gap: 1rem;5  }6}

The condition is:

1(display: flex)

The CSS inside the block only applies if the browser supports that declaration.

If the browser does not support display: flex, the browser ignores the whole @supports block.

Why Feature Queries Are Useful

Feature queries are useful because CSS support can vary.

A browser may support one feature but not another.

Instead of guessing, you can test support directly.

Example:

1.card {2  height: 200px;3}4 5@supports (aspect-ratio: 1 / 1) {6  .card {7    height: auto;8    aspect-ratio: 1 / 1;9  }10}

This gives older browsers a fallback height.

Browsers that support aspect-ratio get the modern version.

The main idea is:

1Write safe CSS first.2Add modern CSS inside @supports.

Basic Syntax

The basic syntax is:

1@supports (property: value) {2  /* CSS rules go here */3}

Example:

1@supports (display: grid) {2  .gallery {3    display: grid;4    grid-template-columns: repeat(3, 1fr);5    gap: 1rem;6  }7}

The browser checks this part:

1(display: grid)

If that declaration is supported, the styles inside the block are used.

A Simple Example

HTML:

1<div class=”layout”>2  <aside>Sidebar</aside>3  <main>Main content</main>4</div>

Fallback CSS:

1.layout {2  display: block;3}

Enhanced CSS:

1@supports (display: grid) {2  .layout {3    display: grid;4    grid-template-columns: 16rem 1fr;5    gap: 2rem;6  }7}

Browsers without grid support use the block layout.

Browsers with grid support use the grid layout.

This is progressive enhancement.

Progressive Enhancement

Progressive enhancement means starting with a basic version that works broadly.

Then you add better styling for browsers that support newer features.

Example:

1.card {2  padding: 1rem;3  border: 1px solid #dddddd;4}5 6@supports (box-shadow: 0 4px 12px rgb(0 0 0 / 0.15)) {7  .card {8    border: 0;9    box-shadow: 0 4px 12px rgb(0 0 0 / 0.15);10  }11}

The card works without the enhancement.

Browsers that support the tested feature get the improved style.

This is safer than relying on modern CSS without a fallback.

Fallback First, Enhancement Second

A common pattern is:

1.element {2  fallback styles3}4 5@supports (modern-property: modern-value) {6  .element {7    enhanced styles8  }9}

Example:

1.media {2  height: 250px;3}4 5@supports (aspect-ratio: 16 / 9) {6  .media {7    height: auto;8    aspect-ratio: 16 / 9;9  }10}

The fallback comes first.

The enhanced version comes second.

This works well because CSS later in the file can override earlier CSS when specificity is equal.

@supports Checks Declarations

Feature queries check whether a browser supports a CSS declaration.

A declaration is a property and value pair.

Example:

1display: grid

So the condition must usually include both:

1@supports (display: grid) {2  /* supported */3}

This is not enough:

1@supports (display) {2  /* invalid */3}

The browser needs a property and value to test.

Testing a Property and Value

This checks whether the browser supports display: grid:

1@supports (display: grid) {2  .layout {3    display: grid;4  }5}

This checks whether the browser supports backdrop-filter: blur(10px):

1@supports (backdrop-filter: blur(10px)) {2  .glass {3    backdrop-filter: blur(10px);4  }5}

This checks whether the browser supports container-type: inline-size:

1@supports (container-type: inline-size) {2  .card-list {3    container-type: inline-size;4  }5}

The test should match the feature you plan to use.

Example: Using @supports with Grid

HTML:

1<div class=”cards”>2  <article>One</article>3  <article>Two</article>4  <article>Three</article>5</div>

Fallback CSS:

1.cards > * {2  margin-bottom: 1rem;3}

Enhanced CSS:

1@supports (display: grid) {2  .cards {3    display: grid;4    grid-template-columns: repeat(3, 1fr);5    gap: 1rem;6  }7 8  .cards > * {9    margin-bottom: 0;10  }11}

Older browsers use vertical spacing with margins.

Grid-supporting browsers use a grid layout with gap.

The fallback is simple.

The enhancement is more advanced.

Example: Using @supports with Flexbox Gap

Flexbox support and gap support are not exactly the same.

A browser may support Flexbox but not support gap in Flexbox.

You can test for gap support:

1@supports (gap: 1rem) {2  .nav {3    gap: 1rem;4  }5}

However, gap can also apply to grid.

So this test tells you whether the browser supports the gap property generally, not necessarily every layout context in older edge cases.

A practical fallback is:

1.nav {2  display: flex;3}4 5.nav > * + * {6  margin-left: 1rem;7}8 9@supports (gap: 1rem) {10  .nav {11    gap: 1rem;12  }13 14  .nav > * + * {15    margin-left: 0;16  }17}

This gives you a margin fallback and a gap enhancement.

Example: Using @supports with aspect-ratio

The aspect-ratio property is useful for media boxes.

HTML:

1<div class=”video”></div>

Fallback CSS:

1.video {2  height: 250px;3  background-color: #dddddd;4}

Enhanced CSS:

1@supports (aspect-ratio: 16 / 9) {2  .video {3    height: auto;4    aspect-ratio: 16 / 9;5  }6}

Browsers that support aspect-ratio use the correct ratio.

Browsers that do not support it still get a usable fixed-height box.

Example: Using @supports with backdrop-filter

The backdrop-filter property can create a frosted-glass effect.

Fallback CSS:

1.panel {2  background-color: rgb(255 255 255 / 0.9);3}

Enhanced CSS:

1@supports (backdrop-filter: blur(12px)) {2  .panel {3    background-color: rgb(255 255 255 / 0.65);4    backdrop-filter: blur(12px);5  }6}

The fallback uses a more solid background.

The enhanced version uses a more transparent background with blur.

This is a good pattern because the content remains readable either way.

Example: Using @supports with Container Queries

Container queries require a container.

Fallback CSS:

1.card {2  padding: 1rem;3}

Enhanced CSS:

1@supports (container-type: inline-size) {2  .card-wrapper {3    container-type: inline-size;4  }5 6  @container (min-width: 30rem) {7    .card {8      display: grid;9      grid-template-columns: 10rem 1fr;10      gap: 1rem;11    }12  }13}

The @supports block checks for container-type.

If the browser supports container queries, the browser applies the container setup and the container query.

If not, the fallback card layout still works.

The not Operator

You can use not to apply CSS when a feature is not supported.

Example:

1@supports not (display: grid) {2  .layout {3    display: block;4  }5}

This means:

1If display: grid is not supported, apply these styles.

However, many developers prefer fallback-first CSS instead.

Instead of this:

1@supports not (display: grid) {2  .layout {3    display: block;4  }5}6 7@supports (display: grid) {8  .layout {9    display: grid;10  }11}

You can usually write:

1.layout {2  display: block;3}4 5@supports (display: grid) {6  .layout {7    display: grid;8  }9}

The fallback-first version is simpler.

When to Use not

Use not when you specifically need styles only for browsers that lack a feature.

Example:

1@supports not (aspect-ratio: 1 / 1) {2  .square {3    height: 200px;4  }5}

This says:

1Only use this fallback if aspect-ratio is not supported.

But for most beginner-friendly CSS, fallback-first is easier:

1.square {2  height: 200px;3}4 5@supports (aspect-ratio: 1 / 1) {6  .square {7    height: auto;8    aspect-ratio: 1 / 1;9  }10}

Use the approach that makes your CSS clearer.

The and Operator

You can require more than one feature.

Example:

1@supports (display: grid) and (gap: 1rem) {2  .gallery {3    display: grid;4    gap: 1rem;5  }6}

This means:

1Apply this CSS only if both display: grid and gap: 1rem are supported.

Another example:

1@supports (container-type: inline-size) and (aspect-ratio: 1 / 1) {2  .card {3    container-type: inline-size;4  }5 6  .thumbnail {7    aspect-ratio: 1 / 1;8  }9}

The and operator is useful when your enhancement depends on multiple features.

The or Operator

You can apply CSS if at least one feature is supported.

Example:

1@supports (backdrop-filter: blur(10px)) or (-webkit-backdrop-filter: blur(10px)) {2  .glass {3    background-color: rgb(255 255 255 / 0.65);4    backdrop-filter: blur(10px);5    -webkit-backdrop-filter: blur(10px);6  }7}

This means:

1Apply this CSS if either backdrop-filter or -webkit-backdrop-filter is supported.

The or operator is useful when different browsers support different versions of a feature.

Grouping Conditions

You can group conditions with parentheses.

Example:

1@supports ((display: grid) and (gap: 1rem)) or (display: flex) {2  .layout {3    gap: 1rem;4  }5}

This can be useful, but complex conditions can become hard to read.

Prefer simple feature queries when possible.

If a condition becomes too complicated, consider whether your fallback and enhancement structure can be simplified.

@supports with Selectors

Feature queries can also test selector support using selector().

Example:

1@supports selector(:has(*)) {2  .field:has(input:focus) {3    outline: 2px solid #2563eb;4  }5}

This checks whether the browser supports the selector inside selector().

In this case, the selector being tested is:

1:has(*)

If the browser supports :has(), the rule inside the block can use it.

Example: Testing :has()

HTML:

1<label class=”field”>2  Email3  <input type=”email”>4</label>

Fallback CSS:

1.field input:focus {2  outline: 2px solid #2563eb;3}

Enhanced CSS:

1@supports selector(:has(*)) {2  .field {3    padding: 0.75rem;4    border: 1px solid #cccccc;5  }6 7  .field:has(input:focus) {8    border-color: #2563eb;9  }10 11  .field input:focus {12    outline: none;13  }14}

Browsers without :has() get the simple focus outline.

Browsers with :has() can style the parent label when the input is focused.

Why selector() Is Useful

Some modern CSS features are selectors, not property-value declarations.

For example:

1:has()2:nth-child()3::marker

For selector features, this syntax is useful:

1@supports selector(:has(*)) {2  /* enhanced selector styles */3}

This is different from property testing:

1@supports (display: grid) {2  /* enhanced property styles */3}

Use the correct type of test.

@supports with Custom Properties

CSS custom properties are widely supported in modern browsers.

You can test them like this:

1@supports (–custom: property) {2  .box {3    –space: 1rem;4    padding: var(–space);5  }6}

However, feature queries for custom properties are not common in everyday CSS anymore.

A more useful pattern is testing the modern feature that uses the variable.

Example:

1.card {2  width: 100%;3}4 5@supports (width: min(100%, 40rem)) {6  .card {7    width: min(100%, 40rem);8  }9}

This tests the actual modern value you want to use.

@supports and Unknown Features

If the browser does not understand the tested declaration, the condition is false.

Example:

1@supports (made-up-property: made-up-value) {2  .box {3    color: red;4  }5}

Browsers do not support that made-up declaration.

So the CSS inside the block does not apply.

This is the main safety feature of @supports.

Unsupported enhancements are ignored.

@supports Does Not Load Polyfills

Feature queries do not add browser support.

They only check support.

This:

1@supports (display: grid) {2  .layout {3    display: grid;4  }5}

does not make grid work in browsers that do not support grid.

It only applies the grid CSS if grid is already supported.

If you need a feature in unsupported browsers, you need a fallback, a different layout, a polyfill if available, or a different design decision.

@supports Does Not Test Design Quality

A browser may support a feature technically, but the design may still need testing.

Example:

1@supports (backdrop-filter: blur(10px)) {2  .panel {3    backdrop-filter: blur(10px);4  }5}

The browser may support backdrop-filter.

But the text may still be hard to read.

Feature queries test support, not whether the result is accessible, readable, or visually good.

Always check the final design.

@supports and the Cascade

CSS inside an @supports block still follows the cascade.

Example:

1.card {2  color: black;3}4 5@supports (display: grid) {6  .card {7    color: navy;8  }9}

If the browser supports grid, the card becomes navy.

Why?

Both selectors have the same specificity.

The @supports rule appears later.

So the later supported declaration wins.

If the browser does not support grid, the block is ignored and the card remains black.

Specificity Still Matters

Feature queries do not override specificity.

Example:

1.card .title {2  color: red;3}4 5@supports (display: grid) {6  .title {7    color: blue;8  }9}

HTML:

1<div class=”card”>2  <h2 class=”title”>Card title</h2>3</div>

Even if grid is supported, the title may stay red.

Why?

The fallback selector is more specific:

1.card .title

The enhanced selector is less specific:

1.title

If you want the enhanced style to override the fallback, use a selector with enough specificity or organise your CSS differently.

Source Order Still Matters

If specificity is equal, later supported CSS wins.

Example:

1.box {2  color: red;3}4 5@supports (display: grid) {6  .box {7    color: blue;8  }9}

The box becomes blue if the browser supports grid.

Now reverse the order:

1@supports (display: grid) {2  .box {3    color: blue;4  }5}6 7.box {8  color: red;9}

The box becomes red because the later normal rule wins.

The @supports block does not automatically have higher priority.

It only controls whether its contents apply.

@supports and Cascade Layers

You can use @supports inside cascade layers.

Example:

1@layer components {2  .card {3    display: block;4  }5 6  @supports (display: grid) {7    .card {8      display: grid;9      gap: 1rem;10    }11  }12}

Both the fallback and enhanced rule are in the components layer.

Inside the same layer, normal specificity and source order apply.

You can also put layers inside @supports:

1@supports (display: grid) {2  @layer components {3    .card {4      display: grid;5    }6  }7}

For beginner projects, it is usually clearer to keep the layer structure simple.

@supports and Media Queries

You can combine feature queries with media queries.

Example:

1@supports (display: grid) {2  @media (min-width: 800px) {3    .layout {4      display: grid;5      grid-template-columns: 16rem 1fr;6      gap: 2rem;7    }8  }9}

This means:

1Only use this layout if grid is supported and the viewport is at least 800px wide.

You can also nest @supports inside @media:

1@media (min-width: 800px) {2  @supports (display: grid) {3    .layout {4      display: grid;5    }6  }7}

Both patterns can work.

Choose the structure that is easiest to read.

Example: Responsive Grid Enhancement

Fallback CSS:

1.products > * {2  margin-bottom: 1rem;3}

Enhanced CSS:

1@supports (display: grid) {2  @media (min-width: 700px) {3    .products {4      display: grid;5      grid-template-columns: repeat(3, 1fr);6      gap: 1rem;7    }8 9    .products > * {10      margin-bottom: 0;11    }12  }13}

This means:

1Small screens use the simple fallback.2Large screens with grid support use the grid layout.

This is a practical use of @supports with @media.

Feature Queries Are Not Browser Queries

Feature queries are different from browser detection.

A browser query would ask:

1Is this Chrome?2Is this Safari?3Is this Firefox?

A feature query asks:

1Do you support this CSS feature?

This is usually better.

Browsers change over time.

A specific browser version may support one feature but not another.

Testing the actual feature is more reliable than testing the browser name.

Do Not Use @supports for Everything

You do not need feature queries around every CSS declaration.

This is unnecessary:

1@supports (color: red) {2  p {3    color: red;4  }5}

Basic CSS features are widely supported.

Use @supports when:

1the feature is modern2support may vary3the feature is important to the layout4you need a fallback5you are using a selector that may not be supported

Do not add feature queries just to make CSS look more advanced.

Use @supports for Riskier Enhancements

Good candidates for feature queries include:

1container queries2:has()3aspect-ratio in older support contexts4backdrop-filter5newer viewport units6newer layout features7advanced color functions8modern CSS functions

Example:

1@supports (height: 100dvh) {2  .app {3    min-height: 100dvh;4  }5}

This applies the dynamic viewport height only when supported.

Example: Modern Viewport Unit Fallback

Fallback CSS:

1.app {2  min-height: 100vh;3}

Enhanced CSS:

1@supports (height: 100dvh) {2  .app {3    min-height: 100dvh;4  }5}

This is useful for mobile layouts.

Older browsers use 100vh.

Browsers that support dvh use 100dvh.

A shorter pattern is also common:

1.app {2  min-height: 100vh;3  min-height: 100dvh;4}

But @supports can make the fallback logic more explicit.

Example: Modern Color Fallback

Fallback CSS:

1.badge {2  background-color: rgb(37 99 235);3}

Enhanced CSS:

1@supports (background-color: color-mix(in srgb, blue, white)) {2  .badge {3    background-color: color-mix(in srgb, blue 80%, white);4  }5}

The fallback uses a normal RGB colour.

The enhanced version uses color-mix().

This lets you use newer color features while keeping a safe fallback.

Example: position: sticky

Fallback CSS:

1.sidebar {2  position: static;3}

Enhanced CSS:

1@supports (position: sticky) {2  .sidebar {3    position: sticky;4    top: 1rem;5  }6}

Browsers that support sticky positioning get the sticky sidebar.

Browsers that do not support it use normal static positioning.

The page still works.

Example: subgrid

CSS Grid subgrid is a more advanced layout feature.

Fallback:

1.card {2  display: grid;3  gap: 1rem;4}

Enhancement:

1@supports (grid-template-columns: subgrid) {2  .card-list {3    display: grid;4    grid-template-columns: repeat(3, 1fr);5  }6 7  .card {8    display: grid;9    grid-template-columns: subgrid;10  }11}

This applies subgrid only when supported.

Without subgrid, the card still has a normal grid layout.

Example: :has() Enhancement

HTML:

1<div class=”todo”>2  <input type=”checkbox” id=”task”>3  <label for=”task”>Finish lesson</label>4</div>

Fallback CSS:

1.todo input:checked + label {2  text-decoration: line-through;3}

Enhanced CSS:

1@supports selector(:has(*)) {2  .todo:has(input:checked) {3    opacity: 0.6;4  }5}

The fallback styles the label.

The enhancement styles the whole .todo item when the checkbox is checked.

@supports with Vendor-Prefixed Features

Some features may have prefixed versions in some browsers.

Example:

1@supports (backdrop-filter: blur(10px)) or (-webkit-backdrop-filter: blur(10px)) {2  .glass {3    background-color: rgb(255 255 255 / 0.65);4    backdrop-filter: blur(10px);5    -webkit-backdrop-filter: blur(10px);6  }7}

This checks for either the standard property or the prefixed version.

Use prefixes only when needed.

Do not add old prefixes blindly.

Common Mistake: No Fallback

This is risky:

1@supports (display: grid) {2  .layout {3    display: grid;4    grid-template-columns: 1fr 2fr;5  }6}

If grid is not supported, .layout has no fallback layout.

Better:

1.layout {2  display: block;3}4 5@supports (display: grid) {6  .layout {7    display: grid;8    grid-template-columns: 1fr 2fr;9  }10}

The page still works without the enhancement.

Common Mistake: Testing the Wrong Feature

This test:

1@supports (display: grid) {2  .card {3    aspect-ratio: 1 / 1;4  }5}

checks for grid support, but the CSS inside uses aspect-ratio.

That may be the wrong test.

Better:

1@supports (aspect-ratio: 1 / 1) {2  .card {3    aspect-ratio: 1 / 1;4  }5}

Test the feature your enhancement actually needs.

Common Mistake: Thinking @supports Overrides Everything

This is wrong:

1CSS inside @supports always wins.

The correct idea is:

1CSS inside @supports applies only when the condition is true.2After that, it still follows the cascade.

Specificity, source order, cascade layers, and !important still matter.

Example:

1.card .title {2  color: red;3}4 5@supports (display: grid) {6  .title {7    color: blue;8  }9}

The title may stay red because .card .title is more specific.

Common Mistake: Making Conditions Too Complicated

This is hard to read:

1@supports ((display: grid) and (gap: 1rem)) or ((display: flex) and (not (gap: 1rem))) {2  .layout {3    margin: 0;4  }5}

A simpler fallback-first structure is usually better.

Example:

1.layout > * + * {2  margin-top: 1rem;3}4 5@supports (display: grid) and (gap: 1rem) {6  .layout {7    display: grid;8    gap: 1rem;9  }10 11  .layout > * + * {12    margin-top: 0;13  }14}

Readable CSS is easier to maintain.

Common Mistake: Using @supports as a Browser Hack

Avoid using feature queries to target a browser indirectly unless you have a strong reason.

Bad idea:

1@supports (-webkit-touch-callout: none) {2  /* Safari-only hack */3}

This kind of CSS can be fragile.

Prefer testing the actual feature you need.

If you are fixing a browser bug, document the reason with a comment.

Common Mistake: Forgetting Older Browsers May Ignore @supports

Browsers that do not support @supports ignore the whole block.

That is usually fine if your fallback is outside the block.

Example:

1.layout {2  display: block;3}4 5@supports (display: grid) {6  .layout {7    display: grid;8  }9}

An old browser that does not understand @supports keeps the block layout.

This is another reason fallback-first CSS is safer.

Debugging @supports

When CSS inside @supports does not apply, ask:

1Does the browser support @supports?2Is the condition true?3Are you testing the correct property and value?4Is the selector inside the block matching the element?5Is another rule overriding it?6Is specificity involved?7Is source order involved?8Are cascade layers involved?9Is the rule inside a media query too?10Is the browser ignoring an invalid declaration?

Use browser developer tools to inspect which declarations are active.

Checking Support in Developer Tools

Most browser developer tools show which CSS rules apply.

If your @supports block does not appear or appears inactive, the condition may be false.

Try testing a simpler condition:

1@supports (display: grid) {2  .test {3    outline: 3px solid red;4  }5}

If the outline appears, the condition is true and the selector matches.

If not, check the condition, selector, and stylesheet loading.

A Practical Debugging Example

CSS:

1.card {2  display: block;3}4 5@supports (display: grid) {6  .card {7    display: grid;8    gap: 1rem;9  }10}

Problem:

1The card is still block layout.

Debug:

1Does the browser support display: grid?2Does the .card selector match?3Is another .card rule later in the CSS setting display: block?4Is the rule inside another condition such as @media?5Is the CSS file loaded?

If another later rule exists:

1.card {2  display: block;3}

after the @supports block, it may override the grid layout.

Full Example: Layout Enhancement

HTML:

1<div class=”page-layout”>2  <aside class=”sidebar”>Sidebar</aside>3  <main class=”content”>Main content</main>4</div>

CSS:

1.page-layout {2  display: block;3}4 5.sidebar {6  margin-bottom: 1rem;7}8 9@supports (display: grid) {10  .page-layout {11    display: grid;12    grid-template-columns: 16rem 1fr;13    gap: 2rem;14  }15 16  .sidebar {17    margin-bottom: 0;18  }19}

Without grid support, the sidebar stacks above the content.

With grid support, the layout becomes two columns.

The fallback is usable.

The enhancement is better.

Full Example: Card Image Ratio

HTML:

1<article class=”card”>2  <div class=”card-image”></div>3  <h2>Card Title</h2>4  <p>Card text.</p>5</article>

CSS:

1.card-image {2  height: 12rem;3  background-color: #dddddd;4}5 6@supports (aspect-ratio: 16 / 9) {7  .card-image {8    height: auto;9    aspect-ratio: 16 / 9;10  }11}

Browsers without aspect-ratio get a fixed-height image area.

Browsers with aspect-ratio get a responsive ratio-based image area.

Full Example: Frosted Panel

HTML:

1<div class=”hero”>2  <div class=”panel”>3    <h1>Welcome</h1>4    <p>This panel uses a fallback and an enhancement.</p>5  </div>6</div>

CSS:

1.panel {2  background-color: rgb(255 255 255 / 0.9);3  padding: 2rem;4  border-radius: 1rem;5}6 7@supports (backdrop-filter: blur(12px)) {8  .panel {9    background-color: rgb(255 255 255 / 0.65);10    backdrop-filter: blur(12px);11  }12}

The panel is readable without the blur effect.

Browsers that support backdrop-filter get the enhanced frosted appearance.

Full Example: Parent Focus with :has()

HTML:

1<label class=”input-field”>2  <span>Email address</span>3  <input type=”email”>4</label>

CSS:

1.input-field input:focus {2  outline: 2px solid #2563eb;3}4 5@supports selector(:has(*)) {6  .input-field {7    display: grid;8    gap: 0.5rem;9    padding: 1rem;10    border: 1px solid #cccccc;11  }12 13  .input-field:has(input:focus) {14    border-color: #2563eb;15  }16 17  .input-field input:focus {18    outline: none;19  }20}

Without :has(), the input itself gets a focus outline.

With :has(), the parent field gets a highlighted border.

The fallback remains accessible.

Full Example: Dynamic Viewport Height

HTML:

1<div class=”app”>2  <header>Header</header>3  <main>Main content</main>4  <footer>Footer</footer>5</div>

CSS:

1.app {2  min-height: 100vh;3  display: grid;4  grid-template-rows: auto 1fr auto;5}6 7@supports (height: 100dvh) {8  .app {9    min-height: 100dvh;10  }11}

Older browsers use 100vh.

Browsers with dynamic viewport height support use 100dvh.

This is helpful for modern mobile layouts.

Full Example: Container Query Enhancement

HTML:

1<div class=”card-container”>2  <article class=”card”>3    <h2>Card Title</h2>4    <p>Card text.</p>5  </article>6</div>

CSS:

1.card {2  padding: 1rem;3  border: 1px solid #dddddd;4}5 6@supports (container-type: inline-size) {7  .card-container {8    container-type: inline-size;9  }10 11  @container (min-width: 35rem) {12    .card {13      display: grid;14      grid-template-columns: 12rem 1fr;15      gap: 1rem;16    }17  }18}

Without container query support, the card remains a simple block.

With container query support, the card can change layout based on its container.

Best Practices for @supports

Write fallback CSS first.

Use @supports for modern enhancements.

Test the feature you actually use.

Keep feature query conditions simple.

Remember that CSS inside @supports still follows the cascade.

Use selector() when testing selector support.

Use and when an enhancement requires multiple features.

Use or when different supported forms are acceptable.

Avoid using @supports as a browser hack.

Do not wrap basic CSS in unnecessary feature queries.

Make sure the fallback is usable.

Test the result in real browsers when the feature is important.

Quick Reference

Basic feature query:

1@supports (display: grid) {2  .layout {3    display: grid;4  }5}

Fallback plus enhancement:

1.layout {2  display: block;3}4 5@supports (display: grid) {6  .layout {7    display: grid;8  }9}

Not supported:

1@supports not (display: grid) {2  .layout {3    display: block;4  }5}

Multiple required features:

1@supports (display: grid) and (gap: 1rem) {2  .layout {3    display: grid;4    gap: 1rem;5  }6}

Either feature:

1@supports (backdrop-filter: blur(10px)) or (-webkit-backdrop-filter: blur(10px)) {2  .glass {3    backdrop-filter: blur(10px);4    -webkit-backdrop-filter: blur(10px);5  }6}

Selector support:

1@supports selector(:has(*)) {2  .field:has(input:focus) {3    border-color: blue;4  }5}

Quick Summary

Feature queries use @supports.

They let you apply CSS only when a browser supports a feature.

The basic syntax is:

1@supports (property: value) {2  selector {3    property: value;4  }5}

Feature queries are useful for progressive enhancement.

Write a safe fallback first.

Then place modern CSS inside an @supports block.

Use not to target browsers without a feature.

Use and when multiple features are required.

Use or when any one of several features is acceptable.

Use selector() to test support for modern selectors such as :has().

Remember that @supports checks feature support, not browser identity.

It does not add support to old browsers.

It only applies CSS when support already exists.

CSS inside @supports still follows normal cascade rules, including specificity, source order, cascade layers, and !important.

Use feature queries when they make your CSS safer, clearer, and more resilient.