Cross-browser by default: How Baseline fallbacks work in Modern Web Guidance

Tara Agyemang

Published: November 12, 2026

Ask an AI coding agent to build a tooltip or a modal dialog, and look closely at the code it writes. Most of the time, the agent pulls in JavaScript to recreate features that are built into the browser. If you prompt the agent to use newer CSS or HTML features instead, it often skips feature detection and fallbacks. This omission leaves users on unsupported browsers with a broken page.

Modern Web Guidance builds browser compatibility into every recommendation. Every guide pairs modern web features with Baseline support data and verified fallback patterns. This post looks at how your agent uses that data to write modern, cross-browser code.

Why coding agents get browser support wrong without guidance

Without guidance, coding agents rarely check which browsers your project needs to support before writing code. Instead, they tend to fall into one of two extremes:

  • Defaulting to legacy code: Model training data is full of legacy patterns, and Modern Web Guidance evaluations show that models still recommend many of these patterns. Agents often write complex JavaScript or add external libraries when a built-in HTML or CSS feature can do the job.
  • Using new features without a safety net: When you ask an agent to use a newer web feature, it usually writes code for supporting browsers and stops there. It skips feature detection and leaves out fallbacks, which breaks the page in browsers that don't support the feature.

Data from the Modern Web Guidance evaluation suite shows how common this gap is. For features that don't yet work across all major browsers, the evaluation suite tests for feature detection, @supports rules, fallbacks, or conditional polyfills. Unguided models pass these checks only 43% of the time. With Modern Web Guidance enabled, the pass rate jumps to 87%.

How Baseline data guides every recommendation

To decide when a web feature needs a fallback, Modern Web Guidance relies on Baseline. Baseline tracks support across the core browser set (Chrome, Edge, Firefox, and Safari on desktop and mobile) with three statuses:

  • Baseline Widely available: The feature has worked across all core browsers for at least 30 months.
  • Baseline Newly available: The feature works across all core browsers, starting from the date the last browser added support.
  • Limited availability: The feature isn't supported across all core browsers yet.

Every Modern Web Guidance guide includes built-in Baseline status and browser version data from the web-features package. When your coding agent loads a guide, it gets the feature's exact support status, release dates, and browser versions alongside the implementation instructions. For example:

Browser support for <dialog closedby>: Limited availability.
Supported by: Chrome 134 (Mar 2025), Edge 134 (Mar 2025), and Firefox 141 (Jul 2025).
Unsupported in: Safari.

By default, Modern Web Guidance follows two rules based on that data:

  • Baseline Widely available features: Your agent uses these features directly without extra feature detection or fallback code. This rule keeps your codebase lean and avoids unnecessary workarounds.
  • Baseline Newly available and Limited availability features: Guides for these features include a verified fallback strategy. Your agent uses the modern feature where supported and provides a clean fallback for other browsers.

Four fallback patterns Modern Web Guidance uses in practice

Not every web feature needs the same kind of fallback. Modern Web Guidance matches each feature to one of four fallback approaches based on how the feature behaves in unsupported browsers:

Fallback pattern When Modern Web Guidance uses it
Progressive enhancement with no fallback code Decorative or additive features that unsupported browsers safely ignore without breaking layout or behavior.
CSS feature detection with the @supports rule Visual or layout styles that depend on a newer CSS feature and can look broken if partially applied.
Lightweight custom JavaScript Interactive HTML attributes or APIs that need a small, zero-dependency script to replicate behavior in older browsers.
Conditionally loaded polyfills Larger CSS or JavaScript features that require a vetted polyfill loaded dynamically only when native support is missing.

Progressive enhancement with no fallback code

Some modern features improve typography, animations, or page load speed without changing how the page works. If a browser doesn't recognize these features, it ignores them and renders the rest of the page normally.

For example, the text-wrap: balance CSS declaration (Baseline Newly available) evens out line lengths in headings.

.balanced {
  text-wrap: balance;
}

The Speculation Rules API (Limited availability) prefetches or prerenders upcoming pages. Unsupported browsers safely ignore <script type="speculationrules"> blocks and unrecognized CSS declarations.

<script type="speculationrules">
  {
    "prefetch": [{
      "where": { "href_matches": "/*" },
      "eagerness": "moderate"
    }]
  }
</script>

Because of this behavior, your agent can add these features directly with no extra fallback code.

CSS feature detection with the @supports rule

Other CSS features change how an element is positioned or styled on screen. If you apply part of the style unconditionally, unsupported browsers might render the element in the wrong place.

For example, anchored container queries (container-type: anchored, Limited availability) on a positioned tooltip let you flip the tooltip's arrow when it flips near the edge of the viewport. In browsers without support for anchored container queries, the arrow can't detect the flip and might point the wrong way. Modern Web Guidance instructs your agent to wrap the arrow styles in an @supports (container-type: anchored) rule so the default arrow appears only in browsers that also support the @container anchored() flip rule.

@supports (container-type: anchored) {
  .tooltip-content::before {
    content: "▼";
    position: absolute;
    inset-block-end: 0;
  }
}

@container anchored(fallback: flip-block) {
  .tooltip-content::before {
    content: "▲";
    inset-block-start: 0;
    inset-block-end: auto;
  }
}

Lightweight custom JavaScript

When an interactive HTML feature isn't supported across all core browsers, pulling in a third-party library can be unnecessary. For self-contained interactions, Modern Web Guidance provides a short, zero-dependency JavaScript fallback behind a feature check.

For example, the closedby="any" attribute on a <dialog> element (Limited availability) lets users close a modal dialog by clicking the backdrop. For browsers that don't support the closedby attribute, the guide includes a small click listener that checks the HTMLDialogElement.prototype object first:

const dialog = document.querySelector('dialog');

if (!('closedBy' in HTMLDialogElement.prototype)) {
  dialog.addEventListener('click', (event) => {
    if (event.target !== dialog) return;

    const rect = dialog.getBoundingClientRect();
    const clickedInDialog =
      rect.top <= event.clientY &&
      event.clientY <= rect.top + rect.height &&
      rect.left <= event.clientX &&
      event.clientX <= rect.left + rect.width;

    if (!clickedInDialog) {
      dialog.close();
    }
  });
}

Conditionally loaded polyfills

For larger platform features, such as CSS anchor positioning (Limited availability) or the Temporal API (Limited availability), writing a custom fallback by hand isn't practical. At the same time, bundling a polyfill for every user adds extra download cost for browsers that already support the feature.

In these cases, Modern Web Guidance directs your agent to check for support first and load a vetted polyfill dynamically with the import() expression from your bundler or a CDN. Supporting browsers download zero extra code, while older browsers fetch the polyfill on demand.

if (!CSS.supports('anchor-name: --a')) {
  await import('@oddbird/css-anchor-positioning');
}

Customize your project's browser support target

By default, Modern Web Guidance treats Baseline Widely available features as safe to use without fallbacks. It requires fallbacks for Baseline Newly available and Limited availability features.

Your project might have different browser requirements. For example, you might target a specific Baseline year, build for an Electron app, or exclude polyfills to keep bundles small.

You can define a custom browser support policy in your project's AGENTS.md or CLAUDE.md file:

## Browser support policy

- Target **Baseline 2024** or earlier. Omit fallbacks and `@supports` blocks for features that reached Baseline in or before 2024.
- Allow **Baseline Newly available** features when paired with a custom fallback of 20 lines or fewer.
- Don't add polyfill dependencies. Prefer CSS `@supports` rules or built-in HTML fallbacks instead.

Every guide includes the Baseline status, release date, and minimum browser versions for each feature. Your agent compares your policy against this compatibility data before writing code. When a feature already meets your target, the agent writes the modern code and skips the fallback code.

Test both the modern path and the fallback path

Writing cross-browser code is only half the job. You also need to test both the modern code path and the fallback path in real browsers.

When you test in a single browser, you verify only one branch of your code. For example, Chrome and Firefox run the native closedby="any" attribute on a <dialog> element, while Safari runs the JavaScript click-outside fallback. If you inspect the dialog in Chrome alone, that fallback listener never runs during your test.

To verify both code paths, connect your coding agent to multiple browser engines at the same time:

With all three tools connected, your agent can open your page across Chrome, Firefox, and Safari in a single workflow. It can then confirm that the native feature and the fallback experience both work as expected.

Get started with Modern Web Guidance

To add Modern Web Guidance to your project, run the interactive installer from your project directory:

npx modern-web-guidance@latest install

If you have an earlier version installed, run the update command to upgrade to version 1.0:

npx modern-web-guidance@latest update

You can also install Modern Web Guidance through plugin marketplaces for Claude Code, Codex, Cursor, Antigravity, GitHub Copilot, WebStorm, Kimi Code, and Grok.

To learn more, explore these resources: