Article
Baseline Makes Browser Support Less Vague
Browser support has always been one of those conversations that can sound simple until a real project is involved.
Can we use this CSS feature? Do we still need that fallback? What happens on older iPhones? Is the client expecting everything to look identical everywhere? Is the CMS editor using the same browser as the target audience? Are we about to add a dependency because one feature feels risky?
Those questions matter. They also become expensive when every decision starts from scratch.
That is why Web Platform Baseline is useful. It gives teams a shared language for browser support, instead of relying on vague memories, old habits or whatever happened to be true on the last project.
But it should not become another badge that replaces thinking.
Baseline makes browser support less vague. It does not remove the need for delivery judgement.
A Shared Line Is Helpful
Baseline is an attempt to make web feature support easier to understand.
Rather than asking teams to inspect every browser compatibility table one feature at a time, Baseline describes whether a feature is newly available, widely available or still limited. A newly available feature is supported across the core browser set. A widely available feature has had that cross-browser support for long enough that most sites can use it with much less concern.
That matters because the web platform has become large.
Modern CSS alone now includes layout, queries, forms, popovers, typography, scroll behaviour, colour functions and interaction states that used to need JavaScript, build tools or fragile workarounds. The question is no longer whether the platform can do enough. Quite often, it can.
The harder question is whether a feature is mature enough for the audience in front of you.
Baseline gives that conversation a better starting point.
The Platform Is Moving Quickly
The May 2026 Baseline digest is a good example of how much is still changing.
Container style queries, the :open pseudo-class, ToggleEvent.source and other features became newly available across the core browser set. Other features, including lh, rlh, clip-path and :user-invalid, moved into widely available territory.
None of those are just novelty items.
Style queries can make components respond to their context without class soup. :open can simplify states that previously needed extra attributes or JavaScript. :user-invalid helps form validation behave in a way that is less hostile to people filling in a form. Line-height units make small layout details easier to express clearly.
These are the sorts of platform improvements that reduce complexity when used well.
For content-managed websites, that is valuable. A Statamic or Laravel-backed site should not carry unnecessary front-end weight just because a team has not revisited what the platform can now handle. The same is true for WordPress, Shopify or bespoke React interfaces. If a native feature is stable enough, accessible enough and maintainable enough, it deserves consideration.
But that last sentence is doing a lot of work.
Stable enough for whom? Accessible enough in which contexts? Maintainable enough by which team?
Baseline helps answer part of that. It does not answer all of it.
Your Audience Is Still The Target
The most important caveat is also the most practical one.
Baseline is a summary of browser support. It is not a substitute for accessibility, usability, performance, security or real device testing. MDN is explicit about that, and the caveat should stay close to the work.
There are good reasons for caution.
Baseline focuses on a defined set of major browsers. Real projects may also involve embedded web views, managed devices, old operating systems, locked-down corporate environments, assistive technology combinations, unusual traffic sources or audiences with slower update cycles.
That does not mean teams should design for every edge case until nothing modern can be used.
It means the target should come from the project, not from habit.
A public sector service, a healthcare information site, a local charity, an e-commerce site with older mobile traffic and an internal tool for a known team can all make different support decisions. Those differences are not signs of inconsistency. They are signs that someone is paying attention.
This is where the newer Baseline tooling becomes interesting.
The Baseline target guidance encourages teams to choose a target based on audience and requirements. The updated Baseline Checker can use Google Analytics browser version data to show how much of a site's actual audience supports specific Baseline targets. Browserslist now supports Baseline queries as well, which means a decision about feature support can be reflected directly in build tooling rather than sitting in a forgotten project note.
That is a healthier model.
Not because tools should make the decision automatically, but because they can make the decision visible.
Progressive Enhancement Still Matters
There is a lazy version of browser support where every feature becomes a yes or no argument.
Can we use it or not? Do we support the browser or not? Is the feature safe or not?
Real front-end work is rarely that binary.
Sometimes the right answer is to use the modern feature with a simple fallback. Sometimes it is to wrap the enhancement in @supports. Sometimes it is to keep the core journey boring and add polish where support exists. Sometimes the feature is technically available but still not worth the complexity. Sometimes the fallback is more expensive than the feature, and the honest answer is to adjust the design.
This is especially true for interface behaviour.
A browser may support the CSS or API you want. That does not prove the interaction is clear, resilient, accessible or pleasant. A form can use modern validation states and still be confusing. A dialog can use newer primitives and still trap someone in a poor journey. A component can pass compatibility checks and still be too fragile for editors to maintain inside a CMS.
Progressive enhancement is not nostalgia. It is a way of separating the essential experience from the enhanced one.
Baseline makes that work easier to plan, because it reduces uncertainty around the platform. It does not make the product judgement disappear.
Tooling Should Record The Decision
The thing I like most about Baseline moving into tools is not the convenience.
It is the accountability.
If a project uses a Baseline target in Browserslist, or checks audience support during planning, that decision becomes part of the system. It can be reviewed when browser usage changes. It can be discussed when a feature request arrives. It can be explained to a client or team without pretending that support policy is just a developer preference.
That is much better than carrying browser support as folklore.
Most teams have some old rules they never quite re-examine. Do not use that property. Avoid that layout mode. Keep this polyfill. Transpile that syntax. Test this one legacy browser even though nobody has looked at the analytics in years.
Some of those habits started for good reasons. Some are now just drag.
Baseline gives teams a prompt to clean that up. Not recklessly, but deliberately.
Choose a support target. Check it against real usage where possible. Document the exceptions. Put the target into the tooling. Test the journeys that matter. Revisit the decision when the project changes.
That is not glamorous work, but it is exactly the kind of work that keeps a front end sustainable.
What This Means For Client Work
For client projects, I think the practical standard is simple.
Use the modern web platform where it makes the product better and the implementation simpler.
Do not use support data as a shield for ignoring people on older or constrained setups.
Do not keep unnecessary dependencies just because nobody wants to revisit a decision.
Do not sell pixel-perfect sameness across every browser when the healthier promise is a robust, accessible experience that adapts well.
And do not let the word Baseline become a shortcut for "we do not need to test this".
The better conversation is more specific:
- What audience are we serving?
- What support target is reasonable for them?
- Which features are safe to use directly?
- Which enhancements need fallbacks?
- Which journeys need manual testing?
- Which decisions should be recorded in the build and the project documentation?
That is the kind of browser support conversation clients can understand. It connects technical decisions to delivery quality, cost, risk and user experience.
It also keeps teams honest.
Less Vague Is The Win
I do not think Baseline needs to be treated as a revolution.
The web has had browser support data for a long time. Developers have had Can I Use, MDN, compatibility tables, analytics, test devices and lived experience. The problem was never a total absence of information.
The problem was that the information often took too much interpretation before a team could make a practical decision.
Baseline improves that.
It gives the industry a shared way to talk about feature maturity. It is reaching documentation, diagnostics and build tools. It reflects the fact that the platform is becoming more capable and more interoperable. Used well, it can help teams ship simpler, more durable front ends.
That is enough.
It does not need to replace judgement to be valuable. The value is that it gives judgement somewhere clearer to stand.
Sources
Need senior support on a web project?
Bring in focused technical help for planning, build, review or long-term support.