Baseline for a stable web, my talk at DevFest Sousse 2024
My DevFest Sousse 2024 talk on Baseline: why browser support tables fail developers, the three Baseline statuses, and where to find them on MDN and Can I use.
On 3 November 2024 I spoke at DevFest Sousse, at EPI, about something every web developer does several times a week without thinking about it: deciding whether a feature is safe to use. The talk was called "Baseline for a stable web", and its subject was the small green check mark that had started appearing on MDN and Can I use the year before. Here is the talk in writing.
Meet Abdallah
I opened with a persona, Abdallah, a web developer with a feature to ship. He wants to use the WebXR API, so he opens Can I use and gets a wall of red cells: partial support here, missing there, version numbers everywhere. He gives up and checks the dialog element instead, on MDN this time, and gets a wall of green with eleven browser columns. Both tables are correct and both are hard to act on. The question Abdallah actually has is "can I ship this to my users?", and neither table answers it directly. That gap is what Baseline exists to close.
What the surveys say
This is not one developer's problem. The MDN Web DNA report asked developers about their biggest frustrations in 2019, and Google has repeated the exercise since. In the research I quoted on stage, 21% of web developers said keeping up with new features is a challenge, another 21% said the same about changes to existing APIs, and 19% struggle to make a design or experience behave the same across browsers. The web platform ships faster than ever; the way we learn what is safe to use has not kept up.
What Baseline is
Baseline was launched by the Chrome team at Google I/O 2023 and is now defined by the W3C WebDX Community Group, with the browser vendors at the table. The idea is one shared answer to "does this work everywhere?" so that developers, designers, product managers and clients can all read the same signal. It is built on a core browser set: Chrome on desktop and Android, Edge on desktop, Firefox on desktop and Android, and Safari on macOS and iOS.
A feature has one of three statuses:
- Widely available. Supported in every core browser for at least 30 months. Use it without a second thought. Canvas is the example I used: on MDN its page opens with the green Baseline banner.
- Newly available. Works in the latest stable version of every core browser, but older browsers and devices may not have it. Decide based on your audience. The Popover API was the fresh example in 2024: it reached Baseline newly available in April that year, and Una Kravets's "Popover API lands in Baseline" article on web.dev was the slide.
- Limited availability. Not yet in all core browsers. Use it with a fallback or not at all. Web Bluetooth was my example, with its orange badge on MDN and the warning that it is experimental.
The year on the badge matters too: "Baseline 2022" means the feature became newly available in 2022, which tells you at a glance how long it has had to spread.
Where you meet it every day
The point of the second half of the talk was that nobody has to go looking for Baseline. It is already in the places developers check:
- MDN shows the status at the top of every feature page, before the compatibility table.
- Can I use shows it in the feature header. Searching for dialog gives "Baseline: widely available across major browsers" above the usual grid.
- web.dev and developer.chrome.com announce when a feature lands in Baseline, which is the moment to reconsider the fallbacks you wrote for it.
- webstatus.dev lists every feature with its status, so you can see what became safe this year.
And the compatibility tables are still there underneath for the cases where you need the detail: a specific old browser, a partial implementation, a known bug.
How I use it in a team
- Write "widely available only" or "newly available allowed" into the project's definition of done. It is a one-line policy that ends most arguments about browser support.
- When a feature reaches widely available, schedule the removal of its polyfill or fallback. That is free performance.
- Use the status in code review: a limited availability feature without a fallback is a review comment, not a judgment call.
The day
DevFest Sousse 2024 filled the EPI amphitheatre, and the questions after the talk were the best part: which status to pick for a public site in Tunisia, where older Android devices are common; whether newly available is enough for an internal tool; and how to argue for dropping a fallback with a client. After the session I held office hours at a desk in the hall, one-on-one, for anyone who wanted to look at their own project's support policy. Thank you to the GDG Sousse team, to EPI for the campus, and to everyone who came.
Links
The Baseline page on web.dev, the Web Platform Status dashboard, the W3C WebDX Community Group, and GDG Sousse.
Frequently asked questions
What is Baseline?
A shared definition of which web features are safe to use. A feature is Baseline when it works in the current and previous versions of Chrome, Edge, Firefox and Safari, on desktop and mobile. It was introduced by Google at I/O 2023 and is now defined by the W3C WebDX Community Group.
What is the difference between Baseline newly available and widely available?
Newly available means the feature works in the latest stable version of every core browser, but older browsers and devices may not have it. Widely available means it has been supported in all of them for at least 30 months, so it is safe to use without a fallback for most audiences.
Where can I see the Baseline status of a feature?
On MDN, at the top of each feature page; on Can I use, in the feature header; on web.dev and developer.chrome.com articles; and on webstatus.dev, which tracks the status of every feature across browsers.
