Perfecting Baseline – Piccalilli

It’s hard to miss the baseline these days. There are banners at the top of most MDN reference pages and on caniuse.com. It also appears as tooltips in various coding editors and developer tools, and people have started mentioning it on blogs, social media, or at conferences. It’s definitely there!

After a few years of existence, it would be fair to say that awareness of Baseline has increased significantly among web developers. People know about the term and have a (sometimes vague) idea of ​​what it means.

Baseline fills a gap but is also incompletepermanent link

For most people, Baseline is filling a gap. For them, this word is a simple way of saying: This feature is supported in all browsersEven if they don’t always know which browsers are included and how long the feature has been supported in them, the term serves as a useful shortcut that conveys a sense of stability and wide availability,

However, for some others, the concept may sometimes be incomplete for a few different reasons:

• Baselines don’t take into account all the browsers they need to support
• Safest Baseline Stage – Baseline is widely available — does not include browser versions old enough that they are still supported
• Baseline says nothing about whether a web feature comes with accessibility challenges
• Baseline does not tell web developers whether it is OK to use a feature that is not yet in the baseline, perhaps as a progressive enhancement, or by using a polyfill.

Those are all legitimate concerns that we at WebDX Group are aware of. In fact, we knew it from the beginning, when the Chrome team first presented the Baseline idea to our group.

Indeed, the way the baseline is defined: a state of not baseline, newly available, And widely available This doesn’t allow us to tell you everything developers should consider before deciding to use a feature. However, talking to web developers when the baseline definition was first being created revealed that even a more nuanced situation would be confusing. The goal was to come up with a traffic light-like situation, which would be in most cases and for most of peopleSpeed ​​up the decision process.

Advertisement

What exactly is the baseline?permanent link

Of course, there can never be a simple traffic light-style condition that summarizes all the factors that decide whether a web feature can be used or not. The baseline is inherently very simple and classifies features into three buckets:

• not baselineIf a feature isn’t supported yet on Chrome (desktop & Android), Safari (macOS & iOS), Edge, Firefox (desktop & Android)
• Baseline newly availableIf it is supported on the above browser
• Baseline is widely availableIf it has been supported for more than 2.5 years on the above browser

This is a proxy of availability that cannot replace careful consideration of factors such as: Is this feature supported on all browsers (and browser versions) used by your customers? Can there be progressive increases in convenience? Is the facility accessible? and more.

The baseline is another data point in your decision matrix. And that’s okay! Baseline is not attempting to replace these other factors. This is a starting point. This helps to get a quick sense of availability, and can be completed.

A word that stuck, and an interconnected list of featurespermanent link

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

• This word stuck. It seems that it has now become part of the vocabulary of web developers. I didn’t know we did, but it seemed like we needed a simple way to reference broader 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 the 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 list of features that we can use in multiple places and be sure what we are talking about. It allows us to link web-related data together in meaningful ways: features of documents, survey data, usage metrics, bug trackers, interop, etc.

completing the baselinepermanent link

The baseline can definitely be completed. Now that we have an initial definition, and now that adoption has increased, we can improve the baseline based on real user feedback and make even greater impact.

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

simple use

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

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

Progressive enhancement, polyfills, and best practices

because there is not a feature widely available That doesn’t mean you can’t use it, and we certainly don’t want to delay the adoption of features. That’s why we’re looking at ways we can map catalogs of web-features to polyfills, best practices, or ways to incrementally enhance them.

With such mapping, we will be able to augment the baseline with useful information that helps developers use features earlier or more safely. But we will also be able to tell developers when it is safe to stop using polyfills.

Other browsers and browser versions

The list of browsers that Baseline considers is: Chrome (Desktop and Android), Firefox (Desktop and Android), Safari (MacOS and iOS), and Edge. This may be too limiting for some projects, so here are some things that may help:

• baseline-browser-mapping, which provides a list of other browsers and their versions, which are based on the engines of the main browsers listed above. This includes Opera, Samsung Internet, KaiOS, and more. And, if you want to use something even simpler, we’re also maintaining browserlist-config-baseline, which lets you target baseline steps via the popular browserlist tool.
• On the WebDX group, we also have an owners group tasked with reevaluating the baseline definition and the browsers taken into account. We meet at least once a year to discuss any significant developments affecting the baseline. So the baseline can and will evolve over time.
• The Google Analytics Baseline Checker tool may also be of interest to you. If you use Google Analytics in your project, you can upload your analytics data to understand the portion of your customer base you’ll include based on the baseline goal you choose.

Then what should you do?permanent link

A baseline is a starting point, a shortcut that gets you started on decision making. Please do not interpret this as a checkbox. I suggest the following argument:

If a feature baseline is widely available

Great, this means it’s been present in all major browser engines for quite some time and is probably already present in most of the browsers your customers use.

If this feature is useful to you, for example to remove a dependency on an expensive JavaScript library, you should be able to use it right away.

However, it’s always a good idea to check resources like MDN for more information about wide browser support and accessibility considerations.

When a feature baseline is newly available

great, it’s all there latest Versions of major browser engines.

Now is a good time to become aware of that feature and the use cases it can unlock. This can help you get rid of custom or third-party libraries you won’t need any time soon, or allow you to implement new product features you haven’t been able to until now. With the right fallback or polyfill for non-supporting browsers, you may even be able to start using this feature now.

When a feature is not a baseline (AKA limited availability)

There are hundreds of really powerful and useful features on the web that don’t have widespread browser support yet. Some of them may be very important for your projects. It would be a pity not to learn about these new features just because they aren’t baseline.

Treating the baseline as one Yes Or No The situation may slow adoption, and therefore also slow developer response, which may help put pressure on browser vendors to implement features.

If you can afford it, take the time to keep an eye on what’s coming up. The Web Platform Feature Explorer is another tool maintained by the WebDX community group that can help get quick information about new features.

If you want to go further and actively participate in the baseline and the data based on it, you can also join the WebDX community group. This group is open to anyone who wants to join, and we value any and all viewpoints on this topic.

WebDX is a group that hopes to create valuable tools and resources for web developers, which is much easier to do when actual web developers are involved!

To join the group, visit the website and click on the join button!

Advertisement