Will It Work Everywhere? Browser Support and @supports

After this lesson you can

• Check whether a CSS feature works in the browsers you need with Baseline, MDN and caniuse.com
• Write a fallback the cascade can use, and a feature query with @supports
• Plan a page with progressive enhancement, so a newer feature is a bonus and the page works without it

Key takeaways

• Baseline says whether a feature works in every major browser. Widely available means for 30 months or more, newly available means in the latest versions, and limited means not yet in all of them.
• caniuse.com shows a feature's support version by version, with known problems and how many people use each browser.
• A browser skips a declaration it doesn't understand, so write the older value first and the newer one after it.
• @supports (read "at supports") applies a group of rules only in browsers that understand a feature.
• Progressive enhancement means the page works for everyone, and newer features are a bonus where the browser can use them.

You read about a new CSS feature that makes headings wrap more neatly, or a reading-progress bar that grows as you scroll, with no JavaScript. You try it, and it works in your browser. Then the question that every developer asks before shipping: will it work on my readers' phones? A client says "it has to work on iPhones". A class assignment says "test in two browsers". Your friend opens your site on an older tablet. This lesson is how you find out, and how you use a new feature without breaking the page for anyone.

Who reads your page, and with what?

A web page doesn't run in one browser. It runs in whatever each reader has: Chrome, Edge, Firefox or Safari, on a laptop or a phone, this year's version or one from two years ago. Chrome, Edge and Firefox update themselves about once a month. Safari updates with the device's system, so a phone that hasn't been updated keeps an older Safari.

A new CSS feature arrives in one browser first, then the others, sometimes years apart. So "does it work?" really means "does it work in the browsers my readers use?" For most sites, that means the current and recent versions of those four, on both laptops and phones.

Baseline: the quick answer

Checking four browsers on two kinds of device for every feature is a lot. Baseline is a label that does it for you. It's agreed by the people who make the browsers, and it comes in three levels:

You'll find the label at the top of every feature's page on MDN (developer.mozilla.org) and on web.dev/baseline. Here are four features from this course, as their labels read in October 2026:

.hero { min-height: 100dvh; }              /* widely available since June 2025 */
h1 { text-wrap: balance; }                 /* newly available since May 2024 */
.comments { content-visibility: auto; }    /* newly available since September 2025 */
.progress { animation-timeline: scroll(); } /* limited: not in Firefox yet */

Labels change as browsers catch up, so check the live page whenever you choose a newer feature.

caniuse.com: the details

When Baseline says "newly available" or "limited", you want the details. On caniuse.com ("can I use"), type the feature's name, such as text-wrap. You get a table with a column for each browser and a row for each version: green where it works, red where it doesn't, and yellow for partial support, with a note saying what's missing.

Two more things make it useful. Point at a version, and it says what share of people around the world use it, so you can tell whether an unsupported version matters. And the Known issues tab lists bugs, such as a browser that supports a property but gets one value wrong.

Try it. Look up :has() and dvh on caniuse.com, then on MDN. Find each one's Baseline label, and the first Safari version that supports it.

Fallbacks the cascade gives you for free

You saw in Look Inside Any Page with Developer Tools that a browser skips a declaration it can't read, without stopping. That's a feature. Write the older, well-known value first and the newer one after it:

.post-hero {
  min-height: 100vh;
  min-height: 100dvh;
}

.price-tag {
  background-color: #b5651d;
  background-color: color-mix(in srgb, #b5651d 80%, white);
}

A browser that understands dvh reads both lines, and the later one wins, as the cascade always decides. A browser that doesn't understand dvh skips the second line and keeps the first. Either way, the reader gets a working page. This is a fallback: the value used when the better one can't be.

Some features need no fallback at all. A browser that doesn't know text-wrap: balance skips it, and the heading wraps the ordinary way. Nothing breaks.

@supports: ask the browser first

Sometimes one line isn't enough. A reading-progress bar needs several declarations and is pointless if the browser can't drive it from scrolling. @supports (read "at supports") asks the browser whether it understands a declaration, and applies the rules inside only if it does. It's also called a feature query:

.reading-progress {
  display: none;
}

@supports (animation-timeline: scroll()) {
  .reading-progress {
    display: block;
    transform-origin: left;
    animation: grow-bar linear;
    animation-timeline: scroll();
  }
}

@keyframes grow-bar {
  from { transform: scaleX(0); }
  to { transform: scaleX(1); }
}

In Firefox today, the bar stays hidden. In Chrome, Edge and Safari, it grows across the top as the reader scrolls down the recipe. You can also write @supports not (...) for the opposite, join conditions with and and or, and test a selector with @supports selector(:has(img)).

Progressive enhancement: the page works, the extras are a bonus

When an escalator breaks down, it becomes stairs. People still get upstairs: it's slower, but it works. Progressive enhancement builds pages the same way. Start with a page that works for everyone: readable text, working links, a sensible layout. Then add newer features on top, so a browser that has them gives a nicer page, and one that doesn't still gives a working one.

/* For everyone: a readable list of steps */
.steps li {
  margin-bottom: 1rem;
  line-height: 1.6;
}

/* A bonus where the browser can do it */
.steps h2 {
  text-wrap: balance;
}

The fallbacks and the @supports rule above are both progressive enhancement. In your textbook you may also meet graceful degradation: building the full version first, then patching it so older browsers still get something usable. Both aim for a page that never breaks; progressive enhancement starts from the version that works everywhere.

Then test it. Open your page in at least two browsers, such as Chrome and Firefox, and on a real phone. If you don't have an iPhone, ask a friend who does to open your link.

Check yourself

2 questions to try on the lesson page.

So what

You can use the newest CSS without leaving anyone out: check the label, give a fallback, and treat what's new as a bonus. Every feature in this course was new once, and the habit of checking is what lets you use the next one early.

Key terms

• Progressive Enhancement
• @supports
• Baseline
• Cascade

Cheat sheets

• Will It Work Everywhere? Browser Support and @supports

Related

• Common Layout Bugs and How to Fix Them
• CSS Performance: What Slows a Page, and Critical CSS