Main article image

Baseline Has Won the Mindshare. Now It Has to Earn the Trust.

If you’ve opened MDN, checked caniuse.com, or hovered a compatibility tooltip in a devtool lately, you’ve seen it: Baseline.

In just a couple of years, Baseline has moved from experiment to everyday vocabulary—a compact way for teams to say, “This feature is safe; it works everywhere that matters.” For many engineers, that alone has been transformative: fewer hours lost spelunking UA matrices, more confidence in modern CSS, JS, and platform APIs.

But as adoption has grown, so has a quiet discomfort among experienced teams.

Baseline is a powerful idea—but in its current form, it’s dangerously easy to misread as absolute truth.

This tension is exactly what the WebDX Community Group is now tackling: turning Baseline from a coarse traffic light into a more nuanced, data-linked system that reflects how engineering teams actually make decisions.

What Baseline Really Says (and Carefully Doesn’t)

Today’s Baseline model is intentionally simple. A feature’s status is determined against four major engine families:

  • Chrome (desktop & Android)
  • Safari (macOS & iOS)
  • Firefox (desktop & Android)
  • Edge

With that, features fall into three buckets:

  1. Not Baseline (Limited Availability) – Not fully supported across the major engines.
  2. Baseline Newly Available – Supported in current versions of all major engines.
  3. Baseline Widely Available – Supported in all major engines for more than 2.5 years.

That’s it. No weighting. No regional browser share. No accessibility insight. No guidance on polyfills or progressive enhancement. No explicit call on whether your long-tail enterprise clients—or your users on Samsung Internet, Opera, KaiOS, or embedded webviews—are actually covered.

For a certain slice of teams, this is fine. For others, it’s incomplete at best and misleading at worst.

The WebDX group always knew this. Baseline was never designed to encode every constraint; it was designed to be a high-signal shortcut. But as it becomes embedded into developer tooling and documentation, its perceived authority grows faster than its nuance.

So the work now is: perfect the shortcut without breaking the simplicity.

The Hidden Win: A Shared Catalog of the Web Platform

One underappreciated consequence of Baseline is foundational: to label features, the community first had to define them.

That effort produced a shared, interoperable catalog of web platform features at a granularity that matches how developers think: not just specs, but concrete capabilities.

This catalog links into an ecosystem of signals and metadata:

  • MDN documentation
  • Browser compat data
  • Interop projects
  • Origin trials
  • WPT (Web Platform Tests)
  • Chrome Platform Status
  • State of CSS/JS/Web surveys
  • Bug trackers and standards positions

That graph is the real infrastructure win. It turns Baseline from a static label into a join key—a way to stitch together availability, stability, usage, and quality data across the web stack.

For teams running large frontends, this means we’re inching toward something long overdue: a coherent, queryable understanding of when a feature is genuinely ready for your users, not just theoretically green across four logos.

Where Baseline Falls Short for Serious Teams

Engineering orgs that treat compatibility as a first-class concern—banks, SaaS platforms, government services, large consumer products—are running into four recurring gaps.

1. Unsupported Browsers and Long-Tail Reality

Baseline focuses on the big four engines, but your production reality may include:

  • Samsung Internet, Opera, Vivaldi
  • Regional browsers
  • Legacy or embedded WebViews
  • Locked-down corporate environments

For these, the WebDX ecosystem offers early answers:

  • baseline-browser-mapping – Maps other browsers to core engines to infer Baseline coverage.
  • browserslist-config-baseline – Lets you target Baseline stages directly via Browserslist, integrating with tools like Autoprefixer or bundlers.

These don’t magically solve policy-heavy or niche environments, but they’re the beginning of a more programmable compatibility model.

2. Baseline Ignores Accessibility (For Now)

Today, Baseline is silent on whether a feature comes with known a11y traps. For teams that take accessibility seriously (and legally have to), a green Baseline label can feel incomplete.

The WebDX group is working to fix this by collaborating with the Accessibility Compat Data project (led by Lola Odelola and others). The goal: attach structured accessibility insights and known issues to the same feature catalog that powers Baseline.

That would allow future tooling to answer questions like:

  • “This API is Baseline Widely Available, but does it interact badly with assistive tech X?”
  • “Is this CSS pattern reliably exposed to screen readers yet?”

It’s not solved yet—but the direction is right.

3. No First-Class Guidance on Progressive Enhancement

Baseline’s simplicity accidentally encourages binary thinking:

  • Baseline Widely Available → “Ship it everywhere.”
  • Not Baseline → “Ignore it until the banner turns green.”

That mindset is hostile to progressive enhancement, slows down adoption of modern platform features, and delays vital feedback to browser vendors.

WebDX’s next step is to map:

  • Features → polyfills
  • Features → fallback patterns
  • Features → progressive enhancement strategies

If this lands, Baseline-aware tooling could say things like:

“This feature is Newly Available. You can safely start using it with these fallbacks, and here’s when you can remove your polyfill based on your traffic.”

That’s the difference between a banner and an engineering tool.

4. Time-Based Confidence Isn’t Context-Based Confidence

“Widely Available” means 2.5+ years of support across major engines. For many products, that’s a solid confidence heuristic.

But your context might demand more rigor. That’s where the Google Analytics Baseline Checker comes in: upload your own analytics data and model how many users are actually covered by different Baseline stages.

This is the right direction: bring your numbers into the decision instead of trusting a global average.

How to Actually Use Baseline Without Outsourcing Your Judgment

Treat Baseline as a starting filter, not a deployment policy.

When a feature is Baseline Widely Available

  • Assume: It’s safe for the vast majority of users.
  • Action: Use it—especially if it lets you drop heavy libraries or brittle workarounds.
  • Still do: Check MDN and compat tables. Confirm alignment with your actual traffic and accessibility requirements.

When a feature is Baseline Newly Available

  • Assume: All major engines support it in recent versions.
  • Action: Start experimenting:
    • Roll out with polyfills or fallbacks.
    • Use progressive enhancement patterns.
    • Use feature detection, not UA sniffing.
  • Strategic angle: This is the sweet spot to modernize your stack while still respecting your users.

When a feature is Not Baseline (Limited Availability)

  • Don’t treat this as a red light.
  • Ask:
    • Is this feature critical enough to support via progressive enhancement?
    • Is your audience skewed to browsers that already support it?
    • Can using it now influence browser vendors by demonstrating demand?
  • Use tools like the Web Platform Features Explorer (from WebDX) to track what’s coming and where it’s supported.

The underlying principle: Baseline should accelerate informed risk decisions, not replace them.

From Banner to Infrastructure: Why This Evolution Matters

Baseline’s rapid adoption created the perception of authority before the ecosystem had fully matured. The next phase—integrating accessibility signals, mapping to polyfills and best practices, expanding browser coverage, enabling org-specific modeling—is what will determine whether Baseline becomes:

  • a long-lived infrastructure layer for compatibility intelligence, or
  • another well-meaning label teams quietly learn to ignore.

The good news: the WebDX community group is explicitly designing for the former. The catalog is open. The data is linkable. The mechanisms for revisiting definitions (including which browsers count) are built in. Baseline is not frozen; it’s versioned by design.

And this is where practitioners come in.

If you’re building design systems, browserslist configs, documentation sites, lint rules, or internal platform tooling, you should be integrating with this ecosystem—and pushing back on where it falls short.

Baseline will only be as useful as the reality it encodes. That reality needs your production pain.

An Invitation to the People Who Actually Ship the Web

Baseline started as a pragmatic heuristic and turned into a shared language. Its next evolution depends on the people who live with compatibility decisions every day.

The WebDX Community Group is open, public, and actively looking for:

  • real-world constraints from product teams,
  • input from accessibility specialists,
  • feedback from framework and tooling authors,
  • and perspectives from regions and markets underrepresented in global stats.

If you care about:

  • dropping dead weight polyfills with confidence,
  • shipping modern features faster without burning edge users,
  • aligning your tooling with a richer, open compatibility graph,

then you have a stake in how Baseline evolves—and a seat at the table.

Because the future of Baseline isn’t a bigger banner. It’s a smarter contract between the people who build the platform and the people who bet their products on it.

Source: “Perfecting Baseline” by Patrick Brosset on piccalil.li, plus additional analysis and context for engineering audiences.