Web Platform Baseline: choose browser features with confidence
Use Baseline 2026 status, progressive enhancement and real audience data to decide when modern CSS, HTML and JavaScript features are ready for production.
Read Baseline labels correctly
Web Platform Baseline summarizes whether a feature works across the core browser set. Newly available means support has arrived across those current engines. Widely available means 30 months have passed since that interoperability point. A yearly target groups the features that became newly available in that year. In 2026, features entering Baseline include container style queries, the CSS :open pseudo-class, custom highlights, WebTransport and the Navigation API.
Baseline is a compatibility signal rather than a product requirement. It does not know the browser versions used by a particular school, office, kiosk or embedded webview. It also does not promise accessibility, performance or a consistent user experience for every use case. Combine the label with audience analytics, device testing and the consequence of failure.
Choose a support target before writing code
For a public utility, start with semantic HTML and a working baseline interaction, then add newer presentation or convenience features. A decorative enhancement can often use a newly available feature safely because older browsers lose only polish. Authentication, payment, document export and form submission deserve a stronger fallback because unsupported behavior can block the whole task.
Write the target in the project documentation. A team might choose Baseline widely available for essential behavior while permitting selected newer features behind feature queries. Review the target periodically rather than adding isolated browser checks throughout the codebase. A clear policy makes bundle decisions, testing and bug triage easier to explain.
Connect Baseline to development tools
Browserslist supports Baseline queries such as baseline widely available or a named year. Compatible build and lint tools can use that target to decide which syntax transformations or warnings are necessary. Current web.dev guidance also points to Baseline data in developer tools and the Web Platform Status dashboard. Automation helps surface assumptions during review instead of waiting for a user to report a blank screen.
Tool output still needs judgment. A transpiler can rewrite some JavaScript syntax, but it cannot automatically reproduce every browser API. CSS can often degrade gracefully, while an unavailable API may require a separate implementation. Test the built production assets, not only source code in the newest local browser.
Use progressive enhancement as the safety net
Begin with meaningful content, labels and native controls. Detect capabilities where behavior depends on an API, and use CSS feature queries for optional styling. Avoid user-agent-string decisions when a direct feature test exists. If the fallback is intentionally unavailable, explain the requirement before the person enters data and provide a route to continue on a supported device.
Maintain a small compatibility matrix covering the oldest supported core browsers, common mobile sizes, keyboard use and reduced-motion preferences. Recheck it when adopting a new Baseline target. This process lets a product use modern CSS and JavaScript without turning every new feature into either a permanent prohibition or an untested production dependency.
Worked example: adopt a modern CSS feature
A team wants to use container style queries for a reusable card. First confirm the feature's current Baseline status and the project's chosen browser target. Build the card with a readable default layout, then place the enhanced rules inside an appropriate feature query. The content, link and keyboard focus must remain usable when the enhanced styling is ignored.
Run the production build in the minimum supported browsers and inspect narrow, wide, zoomed and high-contrast layouts. If analytics show a meaningful audience outside the chosen target, retain the default presentation or use an established fallback. Record the decision in the component documentation so a future developer does not remove the base behavior after seeing only the enhanced version.
Quick checklist
- Define the project's Baseline target.
- Separate essential behavior from visual enhancement.
- Use feature detection and progressive enhancement.
- Connect the target to Browserslist or lint tooling.
- Test production assets on representative devices.
- Review audience data before dropping older support.
Primary references
Standards and platform support change. Use these authoritative sources to check the current specification and migration guidance.