Shipping New CSS Features Safely: Baseline, Fallbacks, and Feature Queries in Practice

Modern CSS features are shipping faster than ever, but "can I actually use this?" remains a question hanging over every developer's head. In one video, YouTube tech creator Kevin Powell systematically breaks down the problem: from what Baseline really means to a practical set of strategies for shipping new features safely. This topic isn't just for people writing CSS by hand—if you use AI-assisted coding, it matters just as much, because some models still implement in piles of JavaScript what CSS has long been able to do, while others boldly reach for features released only weeks ago.

What Baseline Is, and Isn't

According to Kevin Powell, Baseline was originally initiated by the Google Chrome team and is now operated by the WebDX Community Group. It offers three states: widely available (present in all browser engines for at least 30 months), newly available (in all engines, but perhaps only for a month or two), and limited availability (not yet covered across all engines). Once the 30-month mark hits, a new feature graduates from newly available to widely available.

The problem is that many people equate "widely available" directly with "safe to ship," but Powell points out that this comes with a big "it depends." He uses anchor positioning as an example: query tools will show it as nonexistent across all browsers, when in reality all three major engines support it—only their spec statuses differ, leading to muddled information. His advice is straightforward: when you need precise information, go to Can I Use to check version numbers, flag states, and syntax differences, where you'll get a more detailed support picture.

Another easily overlooked variable is "who is the last browser to support it." When paint order first entered widely available, its actual support rate was higher than the earlier-qualifying linear easing function, because browsers follow up in different orders. For many teams, what really matters isn't the global support rate but the last version on iOS to support it—old iPhones are locked by the manufacturer to a particular Safari version, and on iOS every browser is a WebKit-skinned "skin."

The WebDX Community Group is a community group under the W3C, with participation from browser vendors, framework authors, and developer tooling teams, with the goal of unifying availability data for Web platform features. The web-features dataset it maintains tags each feature with a Baseline status and is referenced by documentation sites like MDN and Can I Use. Since the data is maintained collaboratively by multiple parties, Baseline status should in theory be consistent across tools, but in practice queries can still show inconsistent information due to update cadence or differences in feature categorization.

Can I Use is an independent browser compatibility lookup site that lists, in table form, each feature's support across browser versions, including whether prefixes are needed, whether there are known bugs, and the specific differences in partial support. Unlike Baseline's coarse three-tier status, Can I Use provides a version-by-version support matrix, making it better suited to scenarios where you need to precisely determine whether a particular older browser version is usable.

First Question: What Happens If the Feature Fails?

Powell's first principle is: first determine what happens when the feature isn't supported. CSS and JavaScript have completely different failure modes—a JS error halts the entire block of logic, whereas CSS simply skips the line when it encounters an unrecognized property; drop one line from a massive rule block and the page still renders fine.

A typical example of this "progressive enhancement" type of feature is text-wrap: pretty: if supported, you get a bit more typographic polish; if not, almost no one notices. Even more practical is interpolate-size: allow-keywords, which makes animating from height: 0 to height: auto possible with a single line of CSS—something that used to require JavaScript. Powell also addresses the common complaint about progressive enhancement—that it's "unfair" for different users to get different experiences. His rebuttal is interesting: two strangers on different devices will never know the difference in each other's experience, yet we take it for granted that the same user gets different experiences on desktop and mobile.

Progressive enhancement is a web development strategy: first provide baseline functionality that works in all browsers, then layer richer experiences on top for browsers that support new features. Its counterpart, graceful degradation, builds the full experience for modern browsers first, then provides a simplified version for older ones. CSS is naturally suited to progressive enhancement because unknown properties are simply ignored without affecting other rules; JavaScript is different—runtime errors interrupt the current execution context and require extra try-catch or feature detection to isolate the risk.

When Feature Failure Actually Breaks Things: Three Fallback Approaches

Color is a counterexample. If a background or text color fails because of unsupported syntax, the page visibly falls apart. Powell offers a three-tier solution.

Write it twice. Write the hex color value first, then oklch(). The browser uses the first line it reads and overrides it if it understands the second—the cascade mechanism naturally handles the fallback. Maintaining this by hand is tedious, but build tools like PostCSS and Lightning CSS can inject these fallbacks automatically.

Use @supports feature queries. This is Powell's preferred manual approach. He cites Josh Comeau's trick: store the value in a custom property and redeclare it inside an @supports block. For example, first define an easing function variable with widely supported cubic-bezier, then swap in a linear function inside the query block. He emphasizes that you must use @supports here, because custom properties accept any value—even values that are invalid for the use case will be judged valid.

Degrade the whole block. @supports isn't limited to single lines; it can wrap entire blocks of code. Take subgrid: first write a default layout using a regular grid, then enable the subgrid alignment approach inside the query block, avoiding broken rules like row spans when it's unsupported. He also notes that @supports selector() has quite good browser support already and can be safely used for conditional enhancement of selectors like :has().

@supports feature queries have syntax similar to media queries, but they detect whether the browser supports a given CSS declaration or selector. The basic form is @supports (property: value) { ... }, and it also supports combining conditions with and, or, and not. Note that @supports only detects support at the syntax level, not whether the value produces the expected effect on a particular element or in a particular context; for custom properties, since any value is syntactically valid, the query always returns true—which is why Powell emphasizes wrapping the assignment of a custom property in @supports rather than querying the property itself directly.

Polyfills and "Waiting a Bit"

For complex CSS features, polyfills come with performance overhead and capability limits—the more cutting-edge the feature, the harder it is to fully emulate—so adoption requires trade-offs. Another option is simply to wait—Powell admits he often does. Features he enjoys playing with, like sibling-index and sibling-count, need to wait before production use; for syntax that's more about developer experience, like @layer and @scope, using them rashly could break most of your styles outright.

Implications for AI-Assisted Development

Powell specifically notes that this topic is directly relevant to AI writing code. He observes that some models lean toward older approaches, piling on JavaScript, while newer models proactively adopt cutting-edge CSS; Google's modern web guidance skill is entirely based on Baseline, which may cause AI to misjudge a feature's actual usability. In other words, treating Baseline status as the sole criterion isn't sufficient—for humans or for AI.

An actionable checklist thus takes shape: check Can I Use to confirm the precise support surface, prioritize enhancement-type features whose failure is harmless, build fallbacks with double-writing or @supports, and only then consider a polyfill or waiting. The value of this method isn't that it makes you use fewer new features, but that it lets you enjoy new features without worrying they'll break the page.

Background Notes

Polyfill is a piece of code that emulates the behavior of a new feature in browsers lacking native support. CSS polyfills usually work at runtime via JavaScript—parsing stylesheets, computing layout, and injecting equivalent styles—which brings extra script execution and repaint overhead and makes it hard to fully emulate features that involve rendering-engine internals (such as subgrid's track alignment). When deciding whether to adopt a polyfill, you need to weigh the share of target browsers, the polyfill's size and performance cost, and how acceptable the degraded experience is when the feature is missing.