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. When any other rule here conflicts with that one, that one wins. Here is the rest of it.
Two different questions
- Baseline status
- Can I use this?
- Google and the WebDX Community Group, free
- 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. Those three questions are still open once Baseline has answered its own.
If you could guess the verdict from the Baseline status alone, the item has failed and I rewrite it. A publication whose verdicts track the official tiers is a relabelling, and it carries no information you cannot get free from webstatus.dev.
Cleared, Hold, Skip
- Cleared
Do it now. For something that just cleared 30 months, this means all three of these are true: 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.
- Hold
Real, but not yet. Any one of these is enough: the test scores contradict the label, failure is catastrophic rather than graceful, or the fallback is load-bearing and removing it entangles other code. A Hold always names the specific defect. “Hold” on its own is not a verdict, it is a shrug.
- Skip
Works fine, not worth your time. Most silent, expressed by a feature simply never appearing. Occasionally worth printing, and a printed Skip always names its own boundary: Skip, unless you are building a date picker from scratch. More useful than a hedge, and honest about the limit of the claim.
The asymmetry, stated: Cleared needs all three conditions. Hold needs one. Recommending that you delete something is a higher-stakes act than recommending caution, so it carries the higher burden.
The bias worth stating plainly: a feature that just became newly available does not default to Cleared. If anything it skews toward Hold, because those are the newest and least battle-tested implementations on the platform. Newly available is the moment every other publication says “use this now.” This is the one willing to say wait.
Why I read the test data and not just the label
Baseline sits on top of the Web Platform Tests. The summary score tells you that a browser lags. The tests underneath tell you which subtests fail, which is the difference between three obscure edge cases and the main use case. Any score below about 0.9 gets looked at directly.
Two ways a test score lies, both of which have already produced a wrong verdict here:
- The run may predate the feature. In July 2026, the newest Firefox Android test run available was from 10 February 2026. Anything Firefox shipped after February scores near zero there, not because it fails but because it was never run.
field-sizingshipped in Firefox 152 on 16 June 2026 and scored 0.25. I wrote it up as a Hold on the strength of that number, and the Hold was wrong. 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.
masksscores 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.
And what happens to a number I cannot trust: it 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. I prefer every issue to contain at least one Cleared, because a deletion is the most useful thing an issue can hand you, but it is a preference and not a quota. If nothing in a month meets the bar, the issue says so plainly. Manufacturing a deletion to satisfy the format is the exact mechanism by which a judgment publication decays into a changelog with adjectives.
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), the WebKit blog and Firefox release notes, for whether a gap is being actively worked. “Hold, but this is in Interop 2026, so expect it to resolve” is a more useful sentence than “Hold”.
When I get one wrong
Publicly, on the issue page, dated, above the item it corrects, with the original text left visible underneath. It also gets a row in the verdict ledger. Holding opinions means some of them will age badly; that is the cost of the position, not a defect in it, and showing the reasoning is what makes the next verdict worth reading.
Now you know how the sausage is made
One email a month, five things at most, every one a verdict.
Check your inbox. Click the confirmation link and you’re in — first issue Monday 3 August at 6:40 a.m. Pacific.