Every design system eventually gets the same ticket: "Can we use @scope yet?" The person who has to answer it opens three tabs and gets three answers. The W3C's CSS current work page lists CSS Cascading and Inheritance Level 6, the module that defines @scope, as a Working Draft. The CSS Snapshot 2026, the document that is supposed to say what CSS is this year, doesn't mention Level 6 at all. And webstatus.dev says @scope has been Baseline newly available since 24 March 2026, supported in Chrome 143, Firefox 146 and Safari 26.4.

None of those sources is wrong. They answer different questions, and the reason they can disagree at all is that CSS stopped having versions a long time ago. There is no "CSS 2026" release you can target, and no "CSS4" either, so every feature carries its own status. Several organizations track that status, each with its own vocabulary and its own update cadence.

This piece is about reading those signals precisely: what the CSS Working Group's levels and snapshots actually promise, what the W3C maturity labels mean on the day you check them, where decisions are really recorded, and how all of that combines with Baseline. It ends with a decision matrix you can paste into a design-system policy. It builds on two companion pieces in the platform track, one on what Baseline guarantees and one on how web standards mature in general, so I won't re-derive either here. All status facts below were checked on 18 October 2026.

CSS has levels, and only modules have numbers

The cleanest statement of the model is in the Snapshot itself. Its section on CSS levels says CSS "does not have versions in the traditional sense; instead it has levels." Each level is a superset of the one before, and a user agent conforming to a higher level conforms to all lower ones.

That held while CSS was a single document. CSS Level 1 and CSS Level 2 were each one specification. After CSS 2.1, the Working Group split the language into modules, and the Snapshot's introduction gives the reason: modules are "more manageable chunks" that allow "more immediate, incremental improvement to CSS." "CSS Level 3" is the name for that modular era as a whole. From there on, the Snapshot says, "modules are levelled independently". A module that updates something CSS 2 already had starts at Level 3. A module with no CSS 2 equivalent starts at Level 1.

Then comes the sentence that settles every "is this CSS4?" argument. Under the heading CSS Level 4 and beyond, the Snapshot says: "There is no CSS Level 4." Individual modules can reach Level 4 or higher, "but CSS the language no longer has levels." The term "CSS Level 3" survives only to separate the modular era from the monolithic one.

So when you read "Selectors Level 4" or "Cascade Level 6", read the number as a property of that module, nothing more. It tells you how many times that one specification has been extended. It doesn't tell you how stable it is, and it isn't comparable across modules. On today's current-work table, Selectors Level 3 is a Recommendation and Selectors Level 4 is a Working Draft. Cascade Level 4 is a Candidate Recommendation, Level 5 is a Candidate Recommendation too, and Level 6 is a Working Draft. Color Level 4 is a Candidate Recommendation Draft and Color Level 5 a Working Draft. Higher numbers usually mean "newer and less settled", but nothing guarantees it.

The practical consequence for a policy document is that "we support CSS3" or "we target modern CSS" is not a rule anyone can check. A rule has to name features and their status sources, with dates. The rest of this piece is about which sources and which dates.

The Snapshot sorts specs by stability, not by browser support

If there are no versions, something still has to say what CSS consists of right now. That job belongs to the yearly CSS Snapshot. The current edition is CSS Snapshot 2026, a W3C Group Note dated 22 June 2026. Its publication history shows three Notes under that name this year: 26 February, 26 March and 22 June 2026. The current-work page labels it "Latest stable CSS"; the edition before it, the 2025 Snapshot, is a Group Note of 18 September 2025.

Two things about its status matter before you read any of its content. First, it is a Note, not a Recommendation. Its status section says plainly that "Group Notes are not endorsed by W3C nor its Members." It is the Working Group's own summary. Second, and more important for anyone setting policy, its abstract says who it is for: "The primary audience is CSS implementers, not CSS authors, as this definition includes modules by specification stability, not Web browser adoption rate."

That sentence explains most of the confusion. The Snapshot is not a support table. It's the Working Group telling browser engineers which specifications are settled enough to build against. It puts every module it lists into one of four classes:

1. The Official Definition (§2.1): specifications "that we consider stable and for which we have enough implementation experience that we are sure of that stability." It also says inclusion "is based on feature stability only and not on expected use or Web browser adoption."
2. Reliable Candidate Recommendations (§2.2): "largely stable implementations and specifications", held back from Recommendation "due to minor issues or the need for additional implementation reports."
3. Fairly Stable Modules with limited implementation experience (§2.3): design work complete, but they "have not received much testing and implementation experience yet."
4. Modules with Rough Interoperability (§2.4): "widely deployed with rough interoperability", but "their details are not fully worked out or sufficiently well-specified and they need more testing and bugfixing."

Fig. 1 shows the four classes as stacked bands, with a few modules dropping into place, and a few that sit in none of them.

The top class includes specs that are still being republished

Read the lists rather than the headings and the classes stop matching intuition fast.

The Official Definition is not "everything that reached Recommendation". It includes CSS Level 2, Syntax Level 3, Cascade Level 4, Values Level 3, Custom Properties Level 1, Color Level 4, Flexbox, Multi-column, Containment Level 1, Transforms Level 1 and others. Several of those are not Recommendations. On the current-work table, Syntax Level 3 is a Candidate Recommendation Draft, Cascade Level 4 is a CR, and Color Level 4 is a Candidate Recommendation Draft. Color 4's TR page is dated 9 October 2026. The current-work "What's new" list shows four Color 4 updates since mid-September: 13 September, 7 October, 8 October and 9 October. So the Snapshot calls Color 4 part of the definition of CSS while the spec was republished on three consecutive days this October. The Working Group plainly separates "this design is settled" from "the document has finished its process".

The Reliable CR class holds the modules most people would call core layout in 2026: Grid Levels 1 and 2 (which includes subgrid), Media Queries Level 4, Scroll Snap, Cascade Level 5 (cascade layers), Color Adjustment, and Conditional Rules Level 4.

View Transitions Level 1 is "fairly stable", next to Display Level 3, Box Alignment, Text Level 3 and Masking. Its sibling Level 2, which holds cross-document view transitions, isn't in the Snapshot at all.

The rough-interoperability class is where it gets humbling. It holds CSS Transitions and CSS Animations Level 1, Web Animations, Box Sizing Level 3, Logical Properties, Positioned Layout Level 3, Fonts Level 4, Color Level 5, Selectors Level 4, Containment Level 2, CSSOM, CSSOM View and CSS Nesting. These are features every production stylesheet already depends on. The Working Group's honest assessment is that they work well enough to use widely, and that their specs still need work.

What's absent matters as much. Cascade 6 (@scope), Anchor Positioning, Values Level 5 (if(), attr()), Conditional Level 5 (container queries) and Functions and Mixins appear in none of the four classes. Container size queries have been Baseline widely available since 14 August 2025, per web-features 3.43.0, and they still aren't part of any Snapshot class. The Snapshot doesn't say why a module is left out, and "it's still a Working Draft" can't be the rule: Nesting is a WD and sits in §2.4.

"Unstable until CR" is the default, and §4 lists the exceptions

The part of the Snapshot that matters most to implementers, and that authors rarely read, is §3, Requirements for Responsible Implementation. It sets the rules browsers are supposed to follow before shipping a feature to everyone, and it explains why a feature you've seen in a demo might not be in your users' browsers.

§3.1: why one bad value drops the whole declaration

§3.1, Partial Implementations, is the rule every CSS fallback depends on. Renderers "must treat as invalid (and ignore as appropriate) any at-rules, properties, property values, keywords, and other syntactic constructs for which they have no usable level of support." And critically: "if any value is considered invalid (as unsupported values must be), CSS requires that the entire declaration be ignored."

CSS Conditional Rules Level 3 makes the same rule the definition of what @supports tests: a processor supports a declaration "if it accepts that declaration (rather than discarding it as a parse error)", and it must not accept one unless it implements "both the property and the value given" with "a usable level of support." The next two Notes in this series cover feature detection and failure in detail. For this piece, the important thing is that the Working Group's own process depends on it. Partial implementation is allowed only because authors can write fallbacks around it.

§3.2: unstable features and the de facto escape hatch

§3.2.1 defines the word that the rest of the section hangs on. A feature is "unstable" until "its specification has reached the Candidate Recommendation (CR) stage." Unstable features "should not be released broadly for general use", only in controlled settings such as betas, hidden flags or testing partners. The stated reason is lock-in: the Working Group wants to stop production sites "accidentally 'locking in' (through content dependence) certain syntax or behavior that might change later." The same section adds a note for vendors that applies equally to authors: "a pre-CR spec that hasn't changed in awhile is usually more out-of-date than stable."

§3.2.2 covers proprietary extensions: vendor prefixes, kept out of "open (multi-UA) environments such as the World Wide Web."

§3.2.3, "Market Pressure and De Facto Standards", is the escape hatch. An unstable feature may ship unprefixed when at least three UAs implement it (or one has already broken the rules and shipped it), the implementations have rough interoperability, and "the CSS Working Group has recorded consensus that this feature should exist and be released." Rough interoperability is defined as "a subjective judgment", and the section is candid about the cost: it "still usually means painful lack of interop in edge (or not-so-edge) cases."

§3.3 covers the other side: once a spec reaches CR, implementers "should release an unprefixed implementation" of any feature they can show is correct, and submit implementation reports. The Snapshot points to Web Platform Tests for those reports.

§4: what the Working Group cleared in advance

If unstable-until-CR were the whole story, nothing from a Working Draft would ever ship. In practice a lot does, and §4, Safe to Release pre-CR Exceptions, is where the Working Group records the features it has "explicitly and proactively cleared" for broad release before their spec reaches CR. The 2026 list has 20 entries. Among them:

• the flow-relative (logical) sizing, border, margin and padding properties
• aspect-ratio, and the individual translate, rotate and scale properties
• color-mix(), relative color syntax and <color-interpolation-method> for gradients
• :is(), :where(), :has() and selector lists in :not()
• text-box-trim, text-box-edge and their text-box shorthand
• env(), ::marker, accent-color, and a long list of pseudo-classes including :open, :popover-open and :modal
• a set of media features (prefers-reduced-motion, prefers-contrast, forced-colors, prefers-color-scheme and others)
• "Everything in CSS Animations Level 1 and CSS Transitions Level 1"

That last item explains a puzzle from the previous section. CSS Animations and Transitions sit in the lowest Snapshot class, "rough interoperability", and they're also cleared in full for broad release. The two lists answer different questions. §2 classifies how settled the specification text is. §4 records the Working Group's decision that shipping the feature now won't lock the web into something it regrets.

One small detail: the env() entry in the 2026 text reads "save-area-inset-*", a typo for safe-area-inset-*. The list is a record of resolutions, each linked to a decision or a spec. Copy syntax from the spec, not from here.

Maturity labels are dated, and the TR copy is often the oldest one

The second signal is the W3C maturity label: FPWD, WD, CR, REC, with the Candidate Recommendation stage split in two. The W3C Process Document of 18 August 2025 defines a Candidate Recommendation Snapshot (CRS) as a Patent Review Draft that triggers a call for exclusions, and a Candidate Recommendation Draft (CRD) as a publication "to solicit review of intended changes from the previous Candidate Recommendation Snapshot", which "is considered a Working Draft for the purpose of the W3C Patent Policy." The companion piece on standards maturity covers the legal side. Here the useful point is that "CR" on a CSS spec can mean either, and the TR page tells you which.

The CSS current work page (last updated 11 October 2026) is the best single index. On 18 October 2026 it lists, among others:

The table also sorts modules into its own buckets, separate from the Snapshot's: Completed, Stable, Testing, Refining, Revising, Exploring, Rewriting and Abandoned. Selectors Level 4 sits under "Refining". CSS Nesting and Cascade Level 6 sit under "Exploring", which is not a word you'd expect for two features that are Baseline. That makes three classification schemes from the same Working Group, before Baseline even enters.

The published copy can be years behind

The label on current-work is about the module. The document at the /TR/ URL is a specific publication with its own date, and it can be very old.

Open the Cascade Level 5 TR page today and you get a Candidate Recommendation Snapshot dated 13 January 2022. Its status section lists one at-risk feature, the revert-layer keyword. Its publication history ends at that date. Now open the Cascade 5 Editor's Draft, dated 13 April 2026. Its Changes section lists, as the first non-trivial change since the 2022 CRS, "Added the revert-rule keyword." The ED defines revert-rule as rolling back the cascade "as if the current style rule had not been present at all", and gives an example that combines it with if().

Here's why that matters. revert-rule is Baseline newly available since 14 September 2026, shipping in Chrome 148, Firefox 150 and Safari 27. So a keyword that works in every core browser appears in no published W3C version of the spec that defines it. If your policy says "only use features from published CRs", you've excluded something that's interoperable today and included the 2022 text that marks revert-layer at risk. In web-features 3.43.0, revert-layer has been Baseline since 14 March 2022, the same day as the rest of cascade layers.

View Transitions shows the same lag in a milder form. Current-work says "CR". The TR page is a Candidate Recommendation Draft of 28 March 2024, and the history shows the CRS it updates, from 5 September 2023. Both are "CR" in the loose sense. Only one opened a patent exclusion window, and neither is recent.

Editor's Drafts say what they are, if you read the header

The Editor's Draft is where the text actually lives. The Snapshot's background section describes it honestly: it "may or may not reflect Working Group consensus, and can at times be in a self-inconsistent state", and yet "is usually the best (most up-to-date) reference for a spec."

Every ED carries a status header, and it's worth reading literally. The Cascade 6 ED, dated 28 April 2026, says it "is provided for discussion only and may change at any moment." That's the document that defines @scope, which three engines have shipped.

The Changes section is the other thing to read, because it tells you what moved and when. It has its own lag. The Cascade 6 ED's Changes section is headed "Changes since the 21 March 2023 Working Draft". But the Cascade 6 TR page is a Working Draft of 6 September 2024, and the history page confirms three publications: the FPWD of 21 December 2021, and WDs of 21 March 2023 and 6 September 2024. The ED's changelog skips the latest WD. If you diff against the date the changelog names, you'll be comparing against a draft that was superseded two years ago.

One more mismatch worth knowing, because it shows how far behind even the Working Group's own explanations can be. The Snapshot's §1.2 still describes "Proposed Recommendation" as the step between CR and REC. Yet the Snapshot's status section says it's governed by the 18 August 2025 Process, and that Process lists Proposed Recommendation as a retired term, last defined in the 2023 Process. The current-work table's "Upcoming" column still predicts "PR" for several modules too. None of this changes what you can ship. It's a reminder that background prose in a standards document isn't always maintained alongside the rules it describes.

Decisions live in RESOLVED lines, and the drafts follow

If TR copies lag and EDs can be inconsistent, where is the authoritative record of what the Working Group decided? In the GitHub issues of w3c/csswg-drafts. When the group reaches a decision in a meeting, css-meeting-bot posts that part of the minutes to the issue, and the decision appears as a line starting with RESOLVED:.

The masonry debate is the best-known recent example. In issue #12022 the minutes of 19 August 2025 record "RESOLVED: Switch for masonry will be a new display type. Display type must include the word grid in the name." The same day the group adopted a design principle: "Keep masonry consistent with grid wherever practical: deviations need to be strongly justified by the inherent differences between grid vs masonry layout." On 13 November 2025 the follow-up landed: "RESOLVED: masonry switch will be display: grid-lanes". The issue was closed on 8 December 2025 with the label "Closed Accepted by CSSWG Resolution". The grid-lanes Note later in this track picks up what that means for layout.

The anchor-positioning rename is a better case study, because you can follow it all the way into shipping browsers. Fig. 2 lays it out.

Issue #10201 asked what position-visibility: anchors-valid meant by "required anchor references". On 2 April 2026 the minutes record "RESOLVED: Only care about default anchor; rename to anchor-valid." On 6 May 2026 a second resolution followed: "RESOLVED: rename anchors-visible to anchor-visible". The issue was closed on 29 May 2026.

Now look at the drafts. The latest Anchor Positioning Working Draft on TR is dated 27 March 2026, six days before the first resolution, and it still uses anchors-valid. The Editor's Draft, dated 6 September 2026, has the new grammar, always | [ anchor-valid || anchor-visible || no-overflow ]. Its Changes section lists the rename "since the 27 March 2026 Working Draft", citing issue 10201. It also says user agents "may recognize anchors-valid and anchors-visible as legacy value aliases of anchor-valid and anchor-visible (but are not required to)."

Then the engines. Safari 27 shipped on 14 September 2026, per BCD's Safari release data, and WebKit's Safari 27 post (17 September 2026) explains the change in the Working Group's terms. Safari 27 "aligns with the new behavior, and temporarily supports the old keywords for compatibility." The BCD entry for position-visibility on 18 October 2026 records anchor-valid and anchor-visible as Safari 27, Chrome "preview", and not supported in Firefox. Firefox enabled anchor positioning by default in version 147 with the old keywords.

The rename is why anchor positioning is still "limited availability" on webstatus.dev, even though all three engines ship the feature. In web-features 3.43.0 the feature maps to 325 compat keys. 323 of them are Baseline. The two that aren't are css.properties.position-visibility.anchor-valid and .anchor-visible, supported only in Safari 27. A RESOLVED line from April 2026 has held back the headline status of a whole layout system in October 2026, and it will keep doing so until Chrome and Firefox ship the new names.

The method I take from this:

• A spec change is real once there's a RESOLVED line and an Editor's Draft edit that implements it. Check both.
• A TR republication is a lagging indicator. It can trail by months (anchor positioning) or years (Cascade 5).
• Engine adoption of a resolution shows up first in release notes and BCD, and only then in Baseline.

For writing CSS today, the rename has a direct consequence, and §3.1 gives you the tool to handle it. Write the old keyword first and the new one second. Engines that don't know the new name drop the second declaration as invalid and keep the first:

.trigger {
  anchor-name: --trigger;
}

.tooltip {
  position: absolute;
  position-anchor: --trigger;
  position-area: top;
  /* Pre-rename keyword: Chrome 125+, Firefox 147+, Safari 26.2+ */
  position-visibility: anchors-visible;
  /* Renamed per csswg-drafts #10201: Safari 27 as of October 2026 */
  position-visibility: anchor-visible;
}

Safari 27 understands both and keeps the second; Chrome and Firefox drop the second and keep the first. The ED's definition of anchor-visible is word for word the TR draft's definition of anchors-visible, so the two lines mean the same thing. That isn't true of anchors-valid, whose behavior changed to check only the default anchor box, so don't apply this pattern there without testing what each engine does.

Baseline answers a different question, from different data

The third signal is the one most teams already use. web.dev's Baseline page defines two stages. A feature is newly available when it "is supported by all of the core browsers", and widely available when "30 months have passed since the newly interoperable date." Before that it has limited availability. The core browser set is Chrome (desktop and Android), Edge, Firefox (desktop and Android) and Safari (macOS and iOS), and Baseline "is now defined by the WebDX Community Group."

The normative version is the web-features Baseline definition. Two details from it matter here. The low (newly) status needs every current core browser to support the feature "as reported by the current version of @mdn/browser-compat-data, excluding those features identified as having partial_implementation." And the keystone date is "the last release date on which a browser introduced support". The high (widely) status needs that date to be 30 months back and on or before the latest Firefox ESR x.0 release. The companion Baseline piece covers the edge cases in that second rule.

Notice what's missing from both definitions: spec maturity. The only spec test in the web-features definition is a negative one, withholding the status when "the specification text contains discouraging language, such as a deprecation notice". Beyond that, Baseline is computed from BCD, which records what engines ship. It doesn't know whether the spec is a Working Draft, whether a RESOLVED line is about to rename a keyword, or whether the feature appears in the Snapshot. That's deliberate, and it's why Baseline and the CSS Working Group's labels can disagree in both directions.

A feature's status can come from one key

web-features groups many BCD keys into one feature, and by default the feature's status is computed from all of them. A feature can override that. The project's guidelines on status overrides describe compute_from, which "selects one or more compat keys from which to calculate a status for the whole feature" and ignores the rest (the same document now says not to author new ones). The source file for view transitions says compute_from: api.ViewTransition. So the headline status comes from that one key. In 3.43.0 the feature lists 27 compat keys, and 9 of them aren't Baseline: the pageswap and pagereveal event APIs, which Firefox doesn't have (and one of which, Window.pageswap_event, Safari doesn't have either). The feature is still newly available since 14 October 2025, because the key it's computed from is.

That's a reasonable editorial choice: those events belong to cross-document transitions, which is a separate feature. But it means "Baseline" on a feature page never tells you that every part of that feature works everywhere. You have to read the keys.

One script regenerates the whole status table

To see all three signals side by side, I wrote a small script that reads the web-features data behind webstatus.dev and prints, for 15 features, the Baseline status, the low date, how many of the feature's compat keys are Baseline, and the spec URL. It pins the package version so the output is reproducible. The package's npm latest tag was 3.43.0 on 18 October 2026, published on 15 October.

// Node 22+. Pin the version so the table can be regenerated exactly.
const DATA = 'https://unpkg.com/web-features@3.43.0/data.json';

const ids = [
  'color-mix', 'relative-color', 'oklab', 'light-dark', 'has',
  'scope', 'nesting', 'cascade-layers', 'view-transitions',
  'cross-document-view-transitions', 'anchor-positioning', 'if',
  'text-box', 'container-style-queries', 'revert-rule',
];

const { features } = await (await fetch(DATA)).json();

for (const id of ids) {
  const { status, spec } = features[id];
  const keys = Object.values(status.by_compat_key ?? {});
  const held = keys.filter((key) => !key.baseline).length;
  console.log([
    id.padEnd(32),
    String(status.baseline).padEnd(5),
    (status.baseline_low_date ?? '-').padEnd(10),
    `${keys.length - held}/${keys.length} keys`.padEnd(13),
    [spec].flat()[0],
  ].join(' '));
}

I ran it on 18 October 2026 with Node 24.18.0 (node css-status.mjs). In the output, high is widely available, low is newly available, and false is limited:

color-mix                        high  2023-05-09 1/1 keys      .../css-color-5/#color-mix
relative-color                   low   2024-09-16 9/9 keys      .../css-color-5/#relative-colors
oklab                            high  2023-05-09 4/4 keys      .../css-color-4/#ok-lab
light-dark                       low   2024-05-13 1/1 keys      .../css-color-5/#light-dark
has                              high  2023-12-19 1/1 keys      .../selectors-4/#relational
scope                            low   2026-03-24 5/5 keys      .../css-cascade-6/#scope-atrule
nesting                          high  2023-12-11 6/6 keys      .../css-nesting-1/
cascade-layers                   high  2022-03-14 8/8 keys      .../css-cascade-5/
view-transitions                 low   2025-10-14 18/27 keys    .../css-view-transitions-1/
cross-document-view-transitions  false -          0/4 keys      .../css-view-transitions-2/#cross-doc-opt-in
anchor-positioning               false -          323/325 keys  .../css-anchor-position-1/#anchoring
if                               false -          0/1 keys      .../css-values-5/#if-notation
text-box                         false -          9/14 keys     .../css-inline-3/#leading-trim
container-style-queries          low   2026-05-19 1/1 keys      .../css-conditional-5/#style-container
revert-rule                      low   2026-09-14 1/1 keys      .../css-cascade-5/#revert-rule-keyword

I shortened the spec URLs, which all start with https://drafts.csswg.org. Every status and date matches the webstatus.dev API on the same day.

Cross-checking turned up one disagreement, and it's a good illustration of the partial_implementation rule. web.dev's Baseline page says nesting "became Baseline Newly available in August 2023". web-features 3.43.0 gives a low date of 11 December 2023. The nesting source file computes the status from one key, css.selectors.nesting, and BCD's entry for that key marks Chrome 112-119 and Safari 16.5-17.1 as partial: they did "not support nested rules that start with a type selector". Partial support doesn't count, so the keystone is Safari 17.2, released on 11 December 2023 per BCD's Safari release data. August 2023 lines up with Firefox 117, released 29 August 2023 per Mozilla's release dates, the last of the three engines to ship some form of nesting. The page doesn't say where its date comes from, but only the December date follows the Baseline rule.

The three signals disagree in every direction

Put the Snapshot, the maturity labels and Baseline next to each other and you find disagreement in all four directions. These are the cases I'd show anyone writing a support policy.

A Working Draft feature can be Baseline, even widely. @scope is defined in Cascade 6, a Working Draft whose ED is "provided for discussion only", and it's Baseline newly available since 24 March 2026. Nesting (WD, in the Snapshot's rough-interop class) has been widely available since 11 June 2026. :has() (Selectors 4, WD) has been widely available since 19 June 2026, and it's also in §4. Then there's revert-rule, which isn't in any published draft at all, and is newly available.

A feature the Working Group cleared in §4 can still be limited. This is the least-known case, and the one with the most practical bite. text-box is a §4 item, and webstatus.dev lists it as limited. Of its 14 compat keys in 3.43.0, the 9 for the text-box, text-box-trim and text-box-edge properties and their basic values are Baseline, with Firefox 154 as the last engine. The 5 that aren't are the <text-edge> type and its cap, ex, text and alphabetic values. BCD's text-edge entry lists Firefox as "preview" with partial_implementation, and notes "Rendering not implemented (only parsing and serialization)." Those values are what make the feature useful, so the limited status is fair.

::marker is another §4 item and limited too. BCD records Safari since 11.1 as a partial implementation: "Safari support is limited to color and font-size." accent-color, also cleared in §4, is limited because BCD marks Chrome for Android as partial: it "does not maintain minimum contrast for legibility of the control." Safari carried the same partial flag until 26.2. Clearance means the Working Group is comfortable with the feature shipping. It says nothing about whether every engine has.

A CR feature can be partly limited. View Transitions Level 1 is a CR on current-work and "fairly stable" in the Snapshot. Its feature is newly available, but that status comes from one key, as shown above. Cross-document view transitions, defined in Level 2 (a WD, absent from the Snapshot), are limited: Chrome 126 and Safari 18.2, no Firefox. Teams often discuss "view transitions" as one thing. As a policy item it's two, with different answers.

The Official Definition contains a spec still being republished. Color 4 is in the Snapshot's top class, and it's a CRD that changed four times between 13 September and 9 October 2026. Its features (oklch() among them, via the oklab feature) have been widely available since 9 November 2025. In this case all three signals agree that you can use it. The point is only that "Official Definition" doesn't mean "frozen". The Snapshot itself says inclusion "does not mean they are frozen."

Baseline tells you whether a feature runs. Maturity tells you whether it might change under you. RESOLVED lines are the early warning for the second.

A support policy needs two axes: does it run, and will it change

Here's the policy I'd write for a design system, based on everything above. It uses two axes, because the evidence says one isn't enough.

The horizontal axis is support: Baseline status, plus a check of the compat keys you actually use. The vertical axis is spec stability: Snapshot class, §4 listing, or maturity label, plus a scan for open issues and recent resolutions. Fig. 3 places some of the features from this piece on that grid.

Ship

Spec in a Snapshot class or cleared in §4, Baseline widely available. color-mix(), :has(), cascade layers, nesting. Use them without feature queries. Keep the usual fallback discipline for the users you know are on older browsers; your own analytics decides that, not Baseline.

A cleared feature that's only newly available, such as relative color syntax (in §4, newly available since 16 September 2024), sits between this tier and the next. The Working Group has already said shipping it won't cause lock-in, so the open question is how many of your users are on browsers older than the keystone release.

Ship, with care about change

Baseline (newly or widely), but the spec is a WD outside the Snapshot classes, or the feature appears only in an ED. @scope, revert-rule, container style queries, and container size queries too: they've been widely available since 14 August 2025, but Conditional Rules Level 5 is a WD in no Snapshot class. They run everywhere that matters. What's unsettled is the text, so the risk is a behavior change, not a missing feature. Before adopting one, search csswg-drafts for open issues labeled with that module and read any RESOLVED line from the last six months. Put the feature's name and the date you checked in the policy, and revisit it when the module republishes.

Ship behind @supports

Limited availability but a stable or cleared spec, or a limited subfeature of a Baseline feature. text-box, accent-color, ::marker styling beyond color and font-size. Design so the page is correct without the feature, and make sure the adjustment that depends on the feature lives inside the same condition:

.badge {
  padding-block: 0.25em;
}

/* text-box: limited as of October 2026 (no Firefox for <text-edge>) */
@supports (text-box: trim-both cap alphabetic) {
  .badge {
    text-box: trim-both cap alphabetic;
    /* Only rebalance spacing where the trim actually applies */
    padding-block: 0.4em;
  }
}

The padding values are illustrative. The point is structural. If you trim the text box but rebalance the padding outside the condition, browsers without the feature get the new padding and none of the trim. §3.1 and the Conditional Rules support definition are what make this work: a browser without <text-edge> support has to reject the whole declaration, so the condition is false.

Anchor positioning is the case that breaks a one-glance reading of the grid. By headline status it's a WD and limited, which puts it in the next tier. By its keys it's 323 of 325 Baseline, and the two holdouts are a rename with a cascade fallback. I'd treat it as this tier: use the old keywords with the new ones layered on top, and test the parts your components use. That judgment is only possible because step 2 of the checklist below makes you read the keys.

Prototype only

Limited availability and a WD or FPWD spec outside the Snapshot. if() (Chrome and Edge only, since 137), custom functions from the Functions and Mixins FPWD, cross-document view transitions if you need Firefox. Build with them in a branch, file feedback, and keep them out of shared components. These are the features §3.2.1 is about. The Working Group explicitly wants to avoid sites "locking in" behavior that may change, and a design system is the most effective lock-in mechanism a company has.

Avoid

Anything that is neither specified nor shipped. Prefixed proprietary extensions, features that exist only in an explainer, syntax from a blog post written before a RESOLVED line changed it. If you need the capability, write the JavaScript, and keep it small enough to delete.

Six checks place a feature in the matrix

When someone files the "can we use X?" ticket, this is the sequence I'd run:

1. Find the feature on webstatus.dev and read its status and date. Note the web-features version.
2. Open the feature's compat keys (the by_compat_key data, or the BCD entries) and check the ones your code uses. Look for partial_implementation and notes.
3. Find the module on the CSS current-work page. Note the label, then open the TR page and the ED and compare their dates.
4. Check whether the module is in a Snapshot class or the feature is in §4.
5. Search the module's csswg-drafts issues for recent RESOLVED lines touching the feature.
6. Place it in the matrix, write the date in the policy, and set a reminder to re-check.

Each step is a page load or a search. Doing all six is what turns "it's in Chrome" or "MDN has a page for it" into a decision someone can defend in review.

What we don't know

Whether there will be a CSS Snapshot 2027, and when. The 2026 Snapshot says the Working Group hopes to move modules into the Official Definition "in a future snapshot", without a date or cadence. On 18 October 2026, drafts.csswg.org/css-2027/ returns 404. The edition history doesn't settle it either: current-work lists Snapshots for 2007, 2010, 2015, 2017, 2018 and every year from 2020 to 2026, and the 2026 Note was published three times between February and June. A published ED or a CSSWG resolution would settle it.

Why Color 4 is in the Official Definition while it's still a CRD under active revision. The Snapshot's definition of the class ("stable and for which we have enough implementation experience that we are sure of that stability") fits the design. I couldn't find a resolution that explains whether the Snapshot is deliberately ahead of TR status here, or what would move a module out of the Official Definition if one of those revisions turned out to be substantive.

When Cascade 5 will be republished. On 18 October 2026 the TR copy is still the 13 January 2022 CRS, with revert-layer at risk and no revert-rule. The ED has moved on. A new CRD or CRS on the history page would settle it.

When Chrome and Firefox will ship anchor-valid and anchor-visible, and so when anchor positioning becomes Baseline. BCD lists Chrome as "preview" and Firefox as unsupported. On Chrome's side, the Chrome Platform Status entry "Ship anchor-visible and anchor-valid, and deprecate the plural versions" names milestone 157 for desktop and Android, with the status still "Proposed" on 18 October 2026. That's an intent, not a release. I found no equivalent signal for Firefox. Release notes and a BCD update will show it first, and webstatus.dev after that.

How Firefox's preview <text-edge> support behaves under @supports. BCD says the preview implementation parses and serializes the values without rendering them. The Conditional Rules support definition says a processor must not claim support without "a usable level of support". I haven't tested what @supports (text-box: trim-both cap alphabetic) returns in a Firefox build with that preview code, so I can't say whether the pattern above is safe there. Running that query in Firefox Nightly would settle it.

When light-dark() and relative color syntax become widely available. By the definition's arithmetic, 30 months after their low dates (13 May 2024 and 16 September 2024) fall on 13 November 2026 and 16 March 2027. Mozilla's current version list gives the main ESR as 153.5.0esr, and its release list dates 153.0esr to 21 July 2026 and the previous ESR base, 140.0esr, to 24 June 2025. Both keystones predate both, so the ESR clause shouldn't delay them; nesting, with a keystone of 11 December 2023, became widely available exactly 30 months later on 11 June 2026, so the clause isn't holding back features of that age. That's a projection from the rule, not a status anyone has published. Check webstatus.dev after those dates.