Why this topic matters to me now
When a feature-floor idea appears, you immediately want an “official source of truth”.
MDN browser-compat-data almost perfectly fits that role — and almost as perfectly breaks the lab if you use it for the wrong job.
What BCD is in plain words
It is an open compatibility repository: which APIs exist in which browsers and from which version. A machine-readable calendar. Not a blog post. Not a screenshot. The web’s JSON memory.
For an engineer it is a gift: you can check your “milestone ↔ API” matrix against public knowledge instead of keeping it only in your head.
Why check milestone against API
Because a matrix lies more quietly than a detector.
I can honestly measure a browser surface and still dishonestly interpret the measurement — if my calendar is stale, if I mixed up desktop/mobile, if I treated a preview as a required floor.
BCD is an offline check: “did I lie to myself?”
A typical ritual:
- Took a hypothesis from release notes.
- Fixed the expected floor.
- Checked BCD: when the feature actually became stable.
- Only then look at a live browser.
That way the calendar stays a calendar. And the measurement stays a measurement.
Why runtime on BCD is a bad idea
Because BCD describes the world “as documentation tends to count it”, not “what this user has right now”.
A user on a flagged channel. An enterprise build with surfaces cut out. Regional differences. Lag between “appeared in notes” and “present for 95% of clients”. Errors and lag in the dataset itself.
If you drag BCD into runtime as an oracle that says “you are a bot”, you get a documentation detector, not a consistency detector.
Worse — mixing BCD with a verdict. Then any mismatch with the table becomes a moral label. And a mismatch often means: “my model of the world is incomplete”.
In a lab diary this matters ethically. I promised not to publish thresholds and bypass recipes. But even without them you can harm the method: turn a public calendar into a club.
How I keep the boundary
BCD — for calibrating matrices at home. Release notes — for the primary calendar. A live browser and a phone baseline — for measurement. The detector — for finding layer contradictions, not for checking JSON as sacred text.
Three notes in a row (UA → feature-floor → BCD) close the “claim vs measurement” arc at the literacy level. Next in the plan — three rooms of one truth: main, iframe, Worker.
Public anchors: https://github.com/mdn/browser-compat-data https://developer.chrome.com/release-notes/
Public frame (links)
The mdn/browser-compat-data repo and Chrome/Firefox/WebKit release notes are three legs of a stool. One without the other two wobbles: BCD can lag, notes can be marketing, WebKit lives on its own rhythm.
What this changes in detect and/or in the build (without specifics)
BCD helps prepare questions before the experiment. At runtime I listen to the actual surface. In the build I do not “fit to a BCD row”; I check whether the surface drifted from the claimed era. Flags, enterprise policies, partial implementations, and alternative engines on iOS in the EU make “BCD said so” a weak verdict.
What I will not say and why
I do not publish automatic rules of the form “if BCD, then score”. That path leads to false precision.
Short first-person takeaway
BCD is a calendar on the lab wall. A calendar does not sentence the person at the table. I check dates offline and measure the living online.
