Baseline & Interop

For years, "can I use this CSS feature?" meant digging through caniuse.com tables, squinting at version numbers, and guessing whether "supported since Safari 14.1" meant your users actually had it. Baseline is a joint initiative by the major browser vendors (through the WebDX Community Group, with input from MDN and Can I Use) that answers a simpler question: is this feature safe to use across the web today, yes or no?

What Baseline actually measures

Baseline tracks cross-browser availability of a web platform feature — not just "shipped in one browser" but "shipped in Chrome, Edge, Firefox, and Safari." A feature only becomes Baseline once all four have implemented it. That single rule cuts through most of the ambiguity that used to require reading changelogs for four different rendering engines.

Status	Meaning	Practical rule of thumb
`Widely available`	Supported in all major browsers for 30+ months	Use freely, no fallback needed
`Newly available`	Just became supported in all major browsers	Usually safe; consider a fallback for older installs
Limited availability	Not yet supported everywhere	Needs a feature check or progressive enhancement

The 30-month rule

Newly available graduates to Widely available after roughly 30 months across all four browser engines. That window accounts for update cycles on older devices and enterprise browsers that lag behind the latest release, so by the time something is widely available it has genuinely had time to reach almost everyone.

Where you see the Baseline badge

MDN Web Docs — every CSS/HTML/JS property page shows a Baseline status panel near the top
Can I Use — Baseline status is now integrated alongside the classic browser-version tables
web.dev — feature articles reference Baseline status directly
DevTools — Chrome and Edge show Baseline info in the CSS pane for some properties

Checking a feature before you ship it

The fastest workflow: search for the feature name plus "MDN" and read the Baseline panel at the top of the page. It tells you the status in one glance instead of parsing a compatibility matrix.

CSS

/* Example: checking three real features */

/* 1. :has() -- the "parent selector" */
/* Baseline: Newly available (2023) */
.card:has(img) {
  display: grid;
  grid-template-columns: 120px 1fr;
}

/* 2. Container queries */
/* Baseline: Newly available (2023) */
.sidebar {
  container-type: inline-size;
}

@container (min-width: 300px) {
  .widget {
    grid-template-columns: 1fr 1fr;
  }
}

/* 3. Nesting */
/* Baseline: Newly available (2023-2024, depending on syntax) */
.button {
  color: blue;
}

.button:hover {
  color: darkblue;
}

Using Baseline to make adoption decisions

Baseline status is an input to a decision, not the decision itself. Combine it with what you actually know about your audience.

Check your real audience: if analytics show 98% evergreen browsers, "Newly available" features are usually safe today, not just in 30 months
Weigh the failure mode: a feature that fails visually (a slightly different gradient) is lower risk than one that fails functionally (a form that cannot submit)
Prefer features with graceful fallbacks: CSS mostly fails silently, an unsupported property or value is just ignored, so layouts built with fallback values first stay safe automatically

Progressive enhancement as the safety net

Even a "widely available" feature is safer behind @supports when the fallback experience is meaningfully worse without it. @supports lets old and new browsers both get a working layout — just not an identical one.

CSS

/* Baseline-aware progressive enhancement */

.gallery {
  /* Fallback: flexbox, works everywhere */
  display: flex;
  flex-wrap: wrap;
  gap: 16px;
}

.gallery > * {
  flex: 1 1 240px;
}

/* Enhancement: subgrid for perfectly aligned captions */
/* Baseline: Newly available (2024), Safari lagged behind */
@supports (grid-template-rows: subgrid) {
  .gallery {
    display: grid;
    grid-template-columns: repeat(auto-fit, minmax(240px, 1fr));
  }

  .gallery-item {
    display: grid;
    grid-template-rows: subgrid;
    grid-row: span 2;
  }
}

Old/unsupported browser  ->  flex-wrapped grid, no row alignment
New/supported browser    ->  subgrid, images and captions align perfectly across the row

A practical decision framework

Question	If yes	If no
Is it Widely available?	Ship it directly, no fallback needed	Keep reading
Is it Newly available and your audience skews modern?	Ship it, optionally with `@supports` for the last 2-3%	Keep reading
Does the feature degrade gracefully without a fallback?	Ship it as an enhancement, no `@supports` needed	Wrap it in `@supports` with a real fallback layout

Do not wait forever

Teams sometimes treat any non-Baseline feature as radioactive. In practice, most CSS layout and visual features degrade harmlessly — an unsupported gap value or color function is ignored, not a crash. Reserve strict feature-gating for features where the unsupported experience is actually broken, not merely less polished.

Baseline is not a support promise

Baseline reflects desktop-class browser engines. It does not guarantee behavior in embedded webviews, older enterprise browsers pinned to a fixed version, or non-mainstream browsers. If your analytics show meaningful traffic from those, verify separately.

Baseline vs Can I Use — when to reach for which

Baseline gives a quick yes/no gut check while writing code, for day-to-day decisions
Can I Use gives a precise per-browser-version breakdown when you need exact numbers
MDN compatibility tables are the most detailed reference, including partial support notes and flags

Why this matters for teams

Before Baseline, "is this safe to use" was a judgment call that differed between engineers — someone cautious would avoid anything under 95% global support, someone aggressive would ship whatever Chrome supported. Baseline gives teams shared, versioned language: it is Newly available is now a concrete, checkable claim instead of an opinion.

Real feature examples and their status

Concrete examples make the abstract status labels easier to reason about. These are illustrative — always check the live MDN page for the current status, since features move between tiers over time.

Feature	Illustrative status
Flexbox	Widely available (has been for years)
CSS Grid	Widely available
`gap` in flexbox	Widely available
`:has()`	Newly available
Container queries	Newly available
CSS Nesting	Newly available
Subgrid	Newly available, slower rollout across engines
Anchor positioning	Limited availability as of recent checks

This table is illustrative, not authoritative

Baseline status changes as browsers ship updates and the 30-month clock advances. Treat the table above as an example of how to read status labels, not as a current source of truth — always check the live MDN or web.dev page before making a shipping decision.

Baseline in linting and tooling

Baseline data is published as an open dataset, and tooling has started building on top of it directly — instead of a browserslist config expressing raw browser versions, some linters can flag CSS that is not yet Baseline "widely available," giving a much more readable warning than a version-number mismatch.

CSS

/* Conceptual example of a Baseline-aware lint warning */

.card {
  /* Warning: 'subgrid' is not yet Baseline widely available
     (Newly available since 2023) */
  grid-template-rows: subgrid;
}

Baseline-aware tooling is still maturing

Support for Baseline data inside linters, editor extensions, and bundler warnings is a newer development than Baseline itself. Check current tooling documentation for what is actually available in your stack today rather than assuming full editor integration.

A team workflow for adopting Baseline

During code review, treat "is this Baseline Newly/Widely available" as a normal, answerable question — not a judgment call left to the reviewer's memory
For features still Limited availability, require either a @supports fallback or an explicit note on why the degraded experience is acceptable
Revisit any @supports-gated code periodically — a feature that was Limited availability a year ago may now be Widely available, making the fallback removable
Keep the decision framework (earlier on this page) linked in your team's contribution guide so the bar is consistent across reviewers

See how @supports pairs with Baseline decisions in Progressive Enhancement & Graceful Degradation.