Bringing Baseline into Product Development — and Keeping It Safe in Practice

#webdev #javascript #css #html

Baseline gives teams a simple way to answer a hard question: when is a web platform feature safe to use everywhere that matters? Instead of juggling browser-version matrices, you align on a shared, function-level line and make consistent, defensible decisions.

There is also a clear business angle. If a user’s browser silently lacks a feature you rely on, you can lose conversions, trigger avoidable support tickets, and erode trust without anyone noticing the root cause. Treating Baseline as a product standard reduces that risk. It turns a nebulous, recurring debate into a policy you can document, audit, and enforce automatically.

A quick primer on Baseline

Baseline tracks when a feature reaches parity across the four major engines (Safari, Chrome, Edge, and Firefox). It communicates readiness in three stages:

Limited availability — Not yet supported in all Baseline browsers; treat as experimental and avoid for production unless you have a well‑designed fallback.
Newly available — Supported in all current stable releases; good default for early adoption with care.
Widely available — Newly, plus 30 months of universal support; practical proxy for very low risk in the wild.

You can also target by year. For example, “2023” means: allow anything that became Baseline newly available in 2023 or earlier.

It is a feature‑first lens. Rather than anchoring on version lists for each browser, you ask, “Has this capability reached the line?” and get a single answer you can reason about.

Choosing “our Baseline”

Start with Widely as the default. It’s a conservative, low‑friction starting point because it bakes in real‑world adoption time after universal support lands.

Then estimate “our Year.” Use your analytics or RUM to understand the browsers your users actually run. Vary the year (2021, 2022, 2023, …) and estimate coverage. If you use Google Analytics, the Google Analytics Baseline Checker can visualize this; otherwise, you can massage internal logs into the same shape.

Finally, define your exception policy. Some features come with reasonable fallbacks you can ship today and progressively enhance later. Others carry more cross-browser risk and should wait even if they are technically Widely. Write down how exceptions are proposed, reviewed, and documented.

This sequence—safe default, data-informed tuning, explicit exceptions—makes the policy clear and keeps decisions explainable.

Why not rely on UA tables alone?

User-Agent strings are easy to spoof and often polluted by crawlers and scanners. Even when they are accurate, a version label does not capture enterprise policies, flags, or safety modes that can disable capabilities. UA-led policies also force you to manage version matrices, which age poorly and rarely map cleanly to how specifications group features.

Baseline draws the line at the capability itself. Keep UA data for coverage estimates and stakeholder communication, but let features drive the decision.

Bringing it into the workflow

First, set your build/transpile targets to align with your chosen Baseline. Some tools default to Widely already; others let you convert Baseline to a Browserslist query or an esbuild target. The goal is that the code you ship matches the line you agreed on.

Second, catch issues where they happen: in the editor and in CI. ESLint can enforce Baseline for JavaScript, and complementary plugins can do the same for CSS and HTML. When someone reaches for a feature that sits beyond the line, they see a precise, actionable message before it merges.

Third, document the policy. State the default (for example, “Widely”), the way you set the year, and how exceptions work. That turns a tribal norm into policy-as-code and keeps newcomers aligned.

A concrete example: don’t use Date#getYear()/setYear()

Date#getYear() and Date#setYear() are deprecated. They also fall below a sensible Baseline threshold. Reaching for them is a recipe for subtle bugs.

With a Baseline rule enabled, you would see a message like:

One policy, three surfaces: JS, CSS, and HTML

The easiest way to make Baseline “real” for your team is to enable it where code is written. JavaScript is the obvious starting point, but it helps to bring CSS and HTML into the same conversation so your policy feels coherent.

Here is a Flat Config example that wires the three together. Adjust the file globs and the strictness to match your repo.

// eslint.config.js
import baselineJSPlugin from "eslint-plugin-baseline-js";
import cssPlugin from "@eslint/css";
import htmlPlugin from "@html-eslint/eslint-plugin";
import htmlParser from "@html-eslint/parser";

export default [
  // JavaScript/TypeScript: Baseline
  {
    files: ["**/*.{js,ts,jsx,tsx,mjs,cjs}"],
    plugins: { "@baseline-js": baselineJSPlugin },

    rules: {
      "@baseline-js/use-baseline": [
        "error",
        {
          baseline: "widely",
          ignoreFeatures: [],
          ignoreNodeTypes: [],
        },
      ],
    },
  },
  // CSS: Baseline
  {
    files: ["**/*.{css,scss}"],
    plugins: {
      "@css": cssPlugin,
    },
    language: "@css/css",
    rules: {
      "@css/use-baseline": ["warn", { available: "widely" }],
    },
  },

  // HTML: Baseline
  {
    files: ["**/*.{html,htm}"],
    plugins: { "@html-eslint": htmlPlugin },
    languageOptions: { parser: htmlParser },
    rules: {
      "@html-eslint/use-baseline": ["warn", { available: "widely" }],
    },
  },
];

Closing thought

Baseline is a way to agree on reality. Pick a line, show your work, and let tooling hold it for you. That is how teams move fast without gambling with user experience.