How a verdict gets made
Every figure in every issue is checked against live data and sourced, every verdict follows from that evidence, and nothing gets shaped to fit the format.
Two different questions
- Baseline status
- Can I use this?
- Google and the WebDX Community Group
- Cleared verdict
- Should I bother?
- This publication
Baseline is a statement about browser shipping. It says nothing about implementation quality, real-world safety, or whether a feature is worth an afternoon of your time.
If you could work out the verdict from the Baseline status alone, I have not told you anything. Using “Cleared” for everything widely available and “Hold” for everything new is just putting a different label on the same thing.
Cleared, Hold, Skip
- Cleared
Use it now, and drop what it replaces.
For a feature that just passed 30 months, the question is whether there is a deletion here and whether it is safe to make: a fallback exists and costs you something, the change is bounded and verifiable in the diff, and failure is graceful for anyone whose browser still lacks it.
For a feature that just became newly available, the question is whether it is ready or merely available: implementations agree on the tests, it replaces something worse, and failure is graceful.
- Hold
Real, but not yet.
The feature is worth having, but something specific is wrong with it today. For a feature that just passed 30 months: the test scores contradict the label, failure is catastrophic rather than graceful, or the fallback is load-bearing and removing it drags other code with it.
For a feature that just became newly available: one browser lags materially on the tests, the edge cases are still undiscovered, or adopting it would take a refactor, which makes being wrong expensive. Any one of those is enough, and a “Hold” always names which one it is.
- Skip
Works fine, not worth your time.
Nothing to delete at 30 months, or nothing you needed at all when it arrived. Most Skips are silent, expressed by a feature simply never appearing.
One gets printed when the honest answer is “don’t bother” and someone with a megaphone has been saying otherwise: a vendor’s own promotional post, a spike in developer signals, or a week when the newsletters all covered it. A printed Skip always names its own boundary: Skip, unless you are building a date picker from scratch.
A “Cleared” has to meet all three of its conditions. A “Hold” needs only one. Deleting code on my say-so is riskier for you than waiting, so the verdict that asks you to act carries the higher bar.
A feature that has just become newly available does not get a “Cleared” by default. If anything it leans toward a “Hold,” because those are the newest and least battle-tested implementations on the platform. Every other publication will tell you to use it now. Cleared is the one willing to tell you to wait.
Why I read the test data and not just the label
Baseline tracks what browsers have shipped. The Web Platform Tests (opens in a new tab) measure if what they shipped actually works. Both show up on webstatus.dev (opens in a new tab), with the test results boiled down to one score per browser. That score says a browser is behind without saying what is failing, and from there three obscure edge cases look the same as the main use case. So anything below about 0.9 sends me to the individual tests underneath it.
A score is a measurement, and a measurement can be wrong about the thing it is supposed to be measuring. Two ways that happens, and the check that catches each:
The run may predate the feature. In July 2026, the newest Firefox Android test run available was from February 10, 2026. Anything Firefox shipped after that date scores near zero there, not because it fails but because it was never run. field-sizing shipped in Firefox 152 on June 16 and scores 0.25 there, which reads like a defect and is really an empty measurement. So before a low score becomes a “Hold,” the tested build has to be newer than the feature’s ship date in that browser.
The runner may not be comparing what you think. masks scores 1 on Chrome and 0.287 on Chrome Android at the same engine version. Every parsing test passes on both; every screenshot-comparison test passes on desktop and fails on Android. That is the harness, not the browser. So when desktop and mobile split at the same engine version, the question is which kind of test is failing, before any browser gets named as the blocker.
A number I cannot trust does not get laundered into either verdict. I decide on the browsers I can measure, ask what happens if the unmeasured one is broken, and say so in the issue rather than hiding it.
What gets covered
One month of transitions, two pools, nothing else: features that became newly available in the month, and features that passed the 30-month mark in the month. A feature still at limited availability did not transition, so it gets no slot and no verdict, though it may appear inside another item as the reason a workaround still exists.
Five items maximum, and fewer is often better. No cap on any one verdict: if three heavily promoted features in one month are all genuinely not worth your time, an issue saying so about all three is a strong issue. A thin month gets two or three items and a sentence saying it was thin.
I prefer every issue to contain at least one Cleared, because a deletion is the most useful thing an issue can bring you, but iff nothing in a month meets the bar, the issue just says so.
Where the evidence comes from
- webstatus.dev (opens in a new tab) for Baseline status and dates, per-browser versions and ship dates, test summary scores, Chrome usage, and developer signals. The spine of every issue.
- wpt.fyi (opens in a new tab) for the test data underneath those scores, and for when each browser was actually tested.
- caniuse (opens in a new tab) when a verdict is close, because Baseline says “safe in the core browser set” and caniuse says “safe for 97.3% of real traffic.” That gap is exactly where a catastrophic-failure Hold lives.
- MDN browser compat data (opens in a new tab) for the partial-implementation flags and per-subfeature notes that Baseline flattens away.
- Interop (opens in a new tab) for whether a gap is being actively worked on. (“Hold, but this is in Interop 2026, so expect it to resolve” is a more useful sentence than “Hold.”)
When I get a verdict wrong
The correction goes on the issue page, dated, above the item it corrects, with the original text left visible underneath. Its row in the verdict ledger flips to the new verdict and dates the revision. The next letter carries the correction too, because the email that printed the wrong verdict has already been read.
Get the verdicts, with the reasoning
Five verdicts at most, once a month, each with the test data behind it.
Check your inbox. Click the confirmation link and you’re in! First issue Monday, September 14.