Design for Baseline is a practical, feature-focused approach to building for the web. Instead of writing rules that target particular browsers or versions, you target a community-defined compatibility goal called Baseline that tells you which web platform features are interoperable across major browser engines.
This article explains what Baseline is, why it matters, and how to operationalize a ‘design for Baseline, not browsers’ workflow in real projects. You’ll find guidance on progressive enhancement, tooling, analytics, and real-world results from teams that adopted Baseline-driven processes.
What Baseline actually means
Baseline is a compatibility target defined by the community that indicates which web platform features are implemented interoperably across major browser engines. The Web.dev Baseline hub summarizes it as guidance that ‘gives you clear information about which web platform features are ready to use in your projects today.’
Baseline defines two stages for features: ‘Newly available’ means a feature is implemented by all core browsers and is interoperable, while ‘Widely available’ is a later stage reached after roughly 30 months and signals that it is safe to adopt broadly. That 30‑month window helps teams plan progressive adoption and removal of workarounds.
Baseline was initiated by the Chrome team and is now defined and maintained by the W3C Web Platform DX (WebDX) Community Group , a community and browser‑vendor collaboration. This governance model keeps the target practical and vendor‑neutral while staying connected to browser implementation progress.
Why design for Baseline, not browsers
User‑agent sniffing and browser/version matrices are brittle: UA strings are unreliable and they don’t map cleanly to feature availability. MDN and other platform guidance recommend feature detection and capability checks instead of browser detection because versions and channels are not a trustworthy proxy for what a browser can do.
Designing for Baseline shifts your focus from which browser a user runs to which features are interoperable today. That reduces guesswork and lets you speak in feature‑level terms , for example, whether CSS container queries or the :has() selector are safe to use , rather than maintaining long per‑browser support tables.
Baseline also clarifies when polyfills should be removed. Baseline status depends only on native implementations, so a feature’s Baseline state is not satisfied by a polyfill. That makes it easier to know when a native rollout covers your audience and when you can drop legacy shims.
How Baseline fits into a design strategy
Baseline pairs naturally with progressive enhancement: provide essential content and functionality to as many users as possible, and layer modern features for browsers that support them. Web.dev recommends this approach explicitly , start with semantics and content, then enhance with Baseline features.
Use the Baseline stages to manage adoption risk. Treat ‘Newly available’ features as things you can progressively enhance with feature detection (or @supports), and move to direct adoption once a feature reaches ‘Widely available’ status. The roughly 30‑month rule gives product teams predictable windows for gradual adoption.
Concrete examples help: CSS Container Queries were marked Newly available in February 2023, :has() in December 2023, Subgrid in September 2023, and Declarative Shadow DOM in February 2024. Use the Baseline list to choose which modern capabilities to layer into your designs and when.
Tooling and automation that make Baseline actionable
Baseline isn’t just a reference document , it’s being integrated into the tools teams already use. Browserslist added Baseline queries so build pipelines can target Baseline directly, and Vite can target Baseline Widely Available automatically to adjust transpilation and polyfills.
Editor and linting tools also surface Baseline information. ESLint shipped CSS/Baseline support, and VS Code (and other editors) show Baseline info in hovercards, making it easy to see whether a feature is within your chosen target while you code. Those integrations turn the Baseline concept into day‑to‑day guardrails.
For automation and monitoring, the Web Platform Dashboard and WebStatus.dev offer an API to query Baseline status. WebStatus.dev expanded to cover nearly 1,000 features, enabling CI checks and automated reports so teams can enforce Baseline rules in their pipelines and track drift over time.
Operationalizing Baseline in projects
Start by choosing a Baseline target that matches your audience. You can pick a moving target (track Newly/Widely availability) or set a fixed target and revisit it periodically. Combine Baseline targets with your RUM/analytics to measure actual coverage and to decide whether Newly available features are safe behind progressive enhancements.
Configure your tooling to reflect that target: set Browserslist queries, adjust transpilers, enable ESLint rules that prevent accidental use of non‑Baseline features, and add CI checks against the Web Platform Dashboard API. These steps make Baseline a living part of your build and review process instead of an afterthought.
Keep a simple checklist for teams: determine the Baseline target using RUM, prefer feature detection/@supports over UA sniffing, use Baseline‑aware tooling (Browserslist, Vite, ESLint, CI), and use progressive enhancement for Newly available features while adopting Widely available features directly. This checklist helps you convert Baseline theory into repeatable practice.
Real‑world results and lessons from case studies
Organizations that embraced Baseline have reported practical benefits. For example, Cybozu used a Google Analytics Baseline Checker and found that 98.8% of their users already supported the Baseline Widely available target. That allowed them to drop many manual browser support rules and reduce engineering over.
Enterprise teams report fewer quarterly manual support reviews and more enforceable, feature‑level rules in developer workflows. Companies use ESLint and CI checks to warn about non‑Baseline features, which encourages progressive enhancement instead of per‑browser hacks and keeps the codebase simpler to maintain.
RUMvision studies show that adoption patterns vary: Chrome, Edge, and Firefox often reach ~95% adoption for new features within about 3 months, while Safari can lag substantially (some datasets show ~19 months to reach 95%). Even Chrome can take up to ~23 months to hit the last percentiles. Use your real user monitoring to pick the Baseline target that fits your audience and risk profile.
Practical checklist and a short position line
Here’s a short checklist to put into team docs: determine a Baseline target that matches your audience using RUM; prefer feature detection (or @supports) over UA sniffing; use Baseline‑aware tooling like Browserslist, Vite, and ESLint; and use progressive enhancement for Newly available features while adopting Widely available features directly.
Use this short, citable position in your guidelines: Design for Baseline: target interoperable features (Baseline), use progressive enhancement for newer features, and avoid per‑browser UA/version support matrices. That line succinctly captures the approach and is suitable for documentation and design systems.
If you need help, teams can automate checks using the Web Platform Dashboard / WebStatus.dev API, configure their build tools to target Baseline, and run a Baseline coverage check against their analytics to validate impact before removing polyfills or browser rules.
Designing for Baseline streamlines decisions about when a feature is safe to use natively and when to keep fallbacks, and it reduces the cognitive load of per‑browser exception lists. With toolchain support and RUM‑backed targets, teams can adopt modern features with predictable risk management.
Design for Baseline, not browsers , focus on interoperable features, automate checks, and use progressive enhancement to deliver the best experience to modern browsers while preserving essential functionality for everyone.