Baseline 2026: Decoding Browser Support for Modern CSS Features

Baseline is a cross-browser status label, maintained by the Web DX Community Group, that tells you whether a web platform feature works consistently across the latest stable releases of Chrome, Edge, Firefox, and Safari. In 2026 it has effectively replaced the old habit of checking caniuse tables one feature at a time before shipping.

What Baseline Actually Measures

Baseline does not measure "some support somewhere." It measures whether a feature is safe to use without a fallback in the core set of browser engines. There are two tiers:

• Newly available: the feature has shipped in stable versions of all Baseline core browsers (Chrome, Edge, Firefox, Safari). It is technically usable everywhere but may still be rough at the edges in older point releases people haven't updated away from yet.
• Widely available: the feature has been newly available for at least 30 months. At this point you can treat it the way you'd treat flexbox or border-radius: no feature detection, no fallback, just use it.

This 30 month buffer is the part people misunderstand. It is not a support percentage. A feature can be "newly available" and already sit at 98% global usage on caniuse, and still not be "widely available" because the calendar clock hasn't run out. Treat the tier as a statement about risk tolerance and patch-cycle maturity, not a live usage stat.

Baseline data lives directly in MDN's browser compatibility tables now, shown as a small badge above the compat table, so you don't need a separate tool to check it during normal documentation reading.

Is CSS :has() Safe to Ship in 2026?

Yes, and it's a good example of how the tiers actually play out. :has() reached "widely available" status because Safari 15.4, Chrome 105, and Firefox 121 all shipped it, and enough time has passed since the last of those landed. Firefox was the laggard here, having shipped support in December 2023, well after Chrome and Safari.

1/* Style a form group only when it contains an invalid input.
2 No JS validation listener needed just to toggle a class. */
3.form-group: has(input:invalid) {
4 border-color: #d33;
5 background-color: #fdf0f0;
6}
7
8/* Style a card differently when it contains an image,
9 useful for layouts where content is user-generated. */
10.card: has(img) {
11 grid-template-rows: auto 1fr auto;
12}

The caveat: :has() is a relational selector, which means overly broad usage (body:has(.modal-open)) can force the browser to re-evaluate matches across large swaths of the DOM on every mutation. It works everywhere now, but "works" and "cheap" are different claims. Profile it in DevTools' performance panel before you scatter it across a large component tree.

Container Queries: Newly Available Is Not the Same as Ready

Container queries (@container) are a good stress test for the Baseline model because they crossed into "widely available" only in early 2025, after Safari 16 and Firefox 110 filled in the last engine gaps behind Chrome's earlier shipping in Chrome 105 (2022). If you supported browsers released before those versions, container queries silently do nothing rather than throwing an error, which makes bugs here quiet and easy to miss in QA.

1/* Define a containment context on the parent. */
2.sidebar {
3 container-type: inline-size;
4 container-name: sidebar;
5}
6
7/* Switch layout when the container itself narrows,
8 independent of the viewport width. */
9@container sidebar (max-width: 300px) {
10 .card {
11 grid-template-columns: 1fr;
12 font-size: 0.9rem;
13 }
14}

The gotcha most teams hit: container queries need an explicit container-type on an ancestor, and if that ancestor has no defined size (say, it's width: auto inside a flex row with no basis), the query can produce a layout that never resolves cleanly, or resolves to the wrong breakpoint on first paint before reflowing. Test with real content, not lorem ipsum blocks that happen to be a convenient size.

Should You Still Feature-Detect With @supports?

Yes, and Baseline doesn't remove the need for it, it just narrows where you need it. The rule of thumb: if a feature is "widely available," skip @supports and ship the plain rule. If it's "newly available," wrap it, because you're likely still supporting users on browser versions from before the feature landed, particularly on Safari where iOS update adoption lags behind desktop Chrome by months in the real world, regardless of what the release notes say.

1/* Baseline "newly available" feature: subgrid.
2 Wrap it so older engines get a sane fallback grid. */
3.layout {
4 display: grid;
5 grid-template-columns: repeat(3, 1fr);
6}
7
8@supports (grid-template-columns: subgrid) {
9 .layout .nested-grid {
10 grid-template-columns: subgrid;
11 }
12}

One nuance worth knowing: @supports checks whether the browser parses the property/value pair, not whether it behaves correctly. Safari has shipped several properties over the years with partial or buggy implementations that still pass an @supports check. When in doubt, cross-reference the specific version notes on MDN's compatibility data rather than trusting the boolean result alone.

Where Baseline Breaks Down: Non-Core Browsers and Enterprise Environments

Baseline's core set is Chrome, Edge, Firefox, and Safari, evaluated on their latest stable desktop and mobile releases. It says nothing about:

• Older Samsung Internet or UC Browser versions still common in parts of Asia and shown separately on caniuse's regional usage breakdowns.
• Enterprise environments locked to an outdated Chrome or Edge build via group policy, which is more common than most teams assume in B2B SaaS analytics.
• WebViews embedded in native apps, which can trail the standalone browser by one or more major versions depending on when the app was last rebuilt.

If your analytics show meaningful traffic from any of these, Baseline's "widely available" tier is a floor, not a guarantee. Pull your own browser usage report and cross-check it against the caniuse usage table for the specific feature before assuming the badge settles the question.

Practical Rules for Adopting New CSS in 2026

A workflow that has held up across several production codebases I've worked on this year:

• Check the Baseline badge on MDN first. If it says "widely available," write the plain CSS. Don't wrap it in @supports out of habit, that just adds dead code paths nobody will remove later.
• For "newly available" features, check your actual analytics against the specific engine versions that added support. A feature landing in "all four browsers" in late 2025 does not mean your users, who might be three OS updates behind on Safari, actually have it.
• Never trust a single source for a nuanced feature. Cross-reference MDN's compat table, the caniuse entry, and, for anything with layout implications like container queries or :has(), actually test in a real device lab or BrowserStack session rather than DevTools' device emulation, which doesn't replicate every engine quirk around containment and reflow timing.
• Write your fallback path first, then the modern rule. It sounds backwards, but it forces you to confirm the degraded experience is acceptable before you lean on the new feature, rather than discovering it's broken after the fact when someone opens the site on an old iPad.

Testing Your Own Support Matrix

Don't take any article's word for current status, including this one, since Baseline tiers change as browsers ship new versions. Before adopting a feature on a real project:

Open the feature's MDN page and read the compat table's footnotes, not just the badge. Footnotes often list partial support, prefix requirements, or behavioral differences that the boolean badge can't express. Then pull your own site's analytics for browser and OS version distribution over the last 90 days, and check what percentage falls below the versions that introduced the feature you want. If that number is under one or two percent and the degraded experience for those users is just "slightly less polished" rather than "broken," ship it without a fallback. If it's a core interaction, like form validation styling or primary navigation layout, wrap it in @supports regardless of what tier Baseline assigns it. The badge tells you what's possible across browsers. It doesn't know your traffic.