Perfecting Baseline

Summary

I’m the co-chair of the W3C WebDX Community Group, which maintains the data and the definition that powers Baseline. Today, I want to take a step back and talk about what Baseline is starting to mean to web developers, what it is, and what it isn’t. Baseline has become hard to miss these days. There are banners at the top of most MDN reference pages and on caniuse.com. It also shows up in various coding editors and developer tools as tooltips, and people have started to mention it in blogs, social media, or conferences. It’s definitely out there! After a couple of years of existence, it’s fair to say that awareness of Baseline has grown pretty significantly among web developers. People seem to know about the term and have a (sometimes vague) idea about what it means. Baseline fills a gap but is also imperfectpermalink For most people, Baseline is filling a gap. To them, the term acts as a simple way to say: this feature is supported across browsers. Even if they don’t always know which browsers are included and for how long the feature has been supported in them, the term acts as a useful shortcut that conveys a sense of stability and broad availability. For some other people though, the concept can sometimes be imperfect, for a few different reasons: Baseline doesn’t take all the browsers they need to support into account The safest Baseline stage — Baseline Widely Available — doesn’t cover old enough browser versions, which they still support Baseline says nothing about whether a web feature comes with accessibility challenges or not Baseline doesn’t tell web developers if it is OK to use a feature that’s not Baseline yet, perhaps as a progressive enhancement, or by using a polyfill Those are all fair concerns which we’re aware of on the WebDX group. In fact, we knew this from the beginning, when the Chrome team first pitched the Baseline idea to our group. Indeed, the way Baseline is defined: a status of not Baseline, Newly Available, and Widely Available doesn’t...