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 allow us to convey all the things that developers must consider before deciding to use a feature. However, talking to web developers when the Baseline definition was first being created showed that a too nuanced status would be confusing too. The goal was to come up with a traffic light-like of status which would, in most cases and for most people, speed up the decision process.

Advert

What, really, is Baseline?permalink

Of course, there can never be a simple traffic light-style status that summarizes all the factors that go into deciding if a web feature can be used. Baseline is inherently too simplistic and categorizes features in three buckets:

• Not Baseline, if a feature is not yet supported on Chrome (desktop and Android), Safari (macOS and iOS), Edge, Firefox (desktop and Android)
• Baseline Newly Available, if it’s supported on the above browsers
• Baseline Widely Available, if it’s been supported on the above browsers for more than 2.5 years

This is a proxy to availability that can’t replace careful consideration of factors such as: is the feature supported on all browsers (and browser versions) your customers use? Can the feature be a progressive enhancement? Is the feature accessible? And more.

Baseline is one more data point in your decision matrix. And that’s OK! Baseline isn’t trying to replace these other factors. It’s a starting point. It helps get a quick sense of availability, and it can be perfected.

A term that stuck, and an interconnected catalog of featurespermalink

To me, the best things that happened thanks to Baseline are:

• The term itself stuck. It seems to now be part of web developers’ vocabulary. I didn’t know we did, but it seems like we needed a simple way to refer to broad support, and now we have one.
• For the first time, we now have a definitive list of web features, at a level of granularity that makes sense to web developers. Indeed, for Baseline to exist, we first needed to create a list of all the features of the web platform. And we did! Thanks to this, we now have a common catalog of features, which we can use across multiple places and be sure about what we’re talking about. This allows us to link web-related data together in meaningful ways: features to docs, survey data, usage metrics, bug trackers, Interop, etc.

Perfecting Baselinepermalink

Baseline can definitely be perfected. Now that we have an initial definition, and now that adoption has grown, we can improve Baseline based on real user feedback and have even greater impact.

Here are some of the things the WebDX group is actively trying to improve:

Accessibility

If a web feature suffers from known accessibility issues, its Baseline status should take that into account. However, this requires having access to a reliable data source which, so far, has been missing.

We’re hoping to fill that gap by collaborating with Lola Odelola on the Accessibility Compat Data project.

Progressive enhancement, polyfills, and best practices

Because a feature isn’t Widely Available yet doesn’t mean you can’t use it, and we definitely don’t want to delay adoptions of features. That’s why we’re looking at ways in which we could map the catalog of web-features to polyfills, best practices, or ways to progressively enhance them.

With such a mapping, we’d be able to enhance Baseline with useful information that helps developers use features earlier or more safely. But we’d also be able to let developers know when it’s safe to stop using polyfills too.

Other browsers and browser versions

The list of browsers Baseline considers is: Chrome (desktop and Android), Firefox (desktop and Android), Safari (macOS and iOS), and Edge. This can be too limiting for some projects, so here are a couple of things that could help:

• baseline-browser-mapping, which provides the list of other browsers, and their versions, which are based on the engines of the core browsers listed above. This includes Opera, Samsung Internet, KaiOS, and more. And, if you want something even simpler to use, we’re also maintaining browserslist-config-baseline, which lets you target Baseline stages via the popular browserslist tool.
• On the WebDX group, we also have an owners group, which is tasked with re-evaluating the Baseline definition and the browsers that are taken into account. We meet at least once a year to discuss any important developments that might need to impact Baseline. So Baseline can, and will, evolve over time.
• The Google Analytics Baseline Checker tool might also be interesting to you. If you use Google Analytics in your project, you can upload your analytics data to get a sense for the portion of your customer base you’d include depending on the Baseline target you choose.

So what should you do then?permalink

Baseline is a starting point, a shortcut that gets you started on decision making. Please don’t treat it as a checkbox. I suggest the following reasoning:

If a feature is Baseline Widely Available

Cool, it means it’s been in all major browser engines for long enough that most of the browsers your customers use probably have it already.

If the feature is useful to you, for example to remove a dependency on a costly JavaScript library, then you should mostly be able to use it right away.

It’s always a good idea, however, to check resources such as MDN for more information about detailed browser support and accessibility considerations.

When a feature is Baseline Newly Available

Great, it’s in all the latest versions of major browser engines.

Now is a great time to be aware of that feature and the use cases it can unlock. It might help you get rid of custom or third-party libraries you will soon no longer need, or let you implement new product features you haven’t been able so far. You might even be able to start using the feature now, with the right fallbacks or polyfill for non-supporting browsers.

When a feature is not Baseline (AKA Limited Availability)

There are hundreds of really powerful and useful features on the web that don’t have broad browser support yet. Some of them might be very important to your projects. It would be a pitty not to learn about these newer features simply because they’re not Baseline.

Treating Baseline as a yes or no status can slow down adoption, and therefore also slow down developer feedback, which can help pressure browser vendors into implementing features.

If you can afford it, take the time to keep track of what’s coming. The Web platform features explorer is another tool the WebDX community group maintains which can help get quick information about new features.

If you want to go further and take an active part in Baseline and the data it’s based upon, you can also join the WebDX community group. The group is opened to anyone who wants to get involved, and we value any and all points of view on the topic.

WebDX is a group that hopes to create tools and resources that are valuable to web developers, it’s so much easier to do this when actual web developers are involved in it!

To join the group, go to the website and click the join button!

Enjoyed this article? You can support us by leaving a tip via Open Collective

Advert