Preface on asynchrony

One of the defining features of the web is technical asynchrony. Web standards, web clients – like browsers – and web pages are never fully aligned in time. They meet sometimes but most of the time one is ahead or lags behind.

Web standards are usually ahead of browsers and websites. They are designed, then browsers start implementing them. Once a web standard is stable, the implementations are finished and shipped. Then web authors use them on their sites.

But since browser behavior is not fully standardized, web standards may also lag behind browsers.

Browsers are usually ahead of websites. Most websites are developed at one point in time whereas browsers are updated frequently. Today, Firefox and Chromium-based browsers are evergreen, meaning they auto-update to a new major version every four weeks. Safari receives major updates roughly every year.

Browsers allow a glimpse into the past. They need to support all websites ever written since the beginning of the web. Only a few web technologies have been deprecated and removed from browsers. Old sites mostly work in newer browsers, only some features are broken.

But browsers may also lag behind websites. When web authors use web technologies just released in evergreen browsers, most browser versions in use do not support them yet. This was and is a huge problem because some browsers update infrequently or manually. A significant number of people are stuck with old devices, old operating systems and old browsers that cannot be updated.

For web authors, this is daily business. A large part of a web author’s work is dealing with browser compatibility and website interoperability. The situation improved thanks to evergreen browsers. But fundamentally, this is the essence of authoring for the web.

When using an HTML, CSS or JavaScript feature, web authors need to check for its browser support. Can I Use and MDN are the most comprehensive databases. There is an ecosystem of tools that builds on Can I Use data: browserslist is a way to list browser versions a website aims to support. Autoprefixer and @babel/preset-env use browserslist to generate interoperable code.

How to deal with old browsers

The crucial recurring question since the beginning of the web is: How to deal with browsers that do not support a certain web technology feature? The answer is always: It depends! It depends on how the HTML, CSS, JavaScript feature works, on the browser market partition in the target audience, on the importance of the feature for the site, and much more.

Progressive Enhancement and Graceful Degradation are best practices for dealing with old browsers and building interoperable sites. Based on support data, web authors decide whether to use the feature at all. They can test with browser versions that do not support the feature. How do old browsers deal with the new code? How does it affect the user experience?

Web authors can directly use the feature if it enhances the site in newer browsers and does not break anything in older browsers. If it does, web authors can detect the feature and activate it safely. They can add a polyfill or fallback if applicable.

Unfortunately, this is tedious, manual work. A website uses hundreds, if not thousands of distinct web features across HTML, CSS, SVG, JavaScript, DOM, WebGL, images, audio, video, etc. Web authors need to investigate and group the features to make pragmatic browser support decisions.

That is to say, I can fully understand that web authors want to make this task easier and less time-consuming.

Google’s Baseline initiative

At Google’s developer conference, Google recently announced the Baseline initiative. See also Introducing Baseline and Rachel Andrew’s YouTube video.

Google Baseline aims to make it easier for web authors and web publishers to think and talk about browser support. Baseline is a line in the sand indicating which web platform features are safe to use. Features in Baseline have cross-browser support, they are interoperable, with no major issues in any browser engine. As Rachel Andrew explains in the video, if a feature is part of Baseline, our aim is that most web teams should feel confident to just use it.

The blog post lists the pursued benefits:

• When planning a project, rather than needing to list specific browser versions, you can set a requirement to use features that are part of Baseline.
• When publishing a library, you can help potential users understand support of features used (and therefore whether it is safe to use on their site) by declaring support for Baseline.
• When writing a tutorial, you can tell readers that everything described is in Baseline. Your reader then knows this is a solution they can incorporate into a project.

The crucial technical definition of the Google Baseline is: Features become part of Baseline when they are supported in the current and previous version of all major browsers—Chrome, Edge, Firefox, and Safari.

“Widely supported” Cascade Layers

While I value Google’s manifold efforts to improve web interoperability, I don’t think that Google Baseline clears things up and delivers on its promises. It is a simplification of the reality. It gives web authors a false impression of how browser compatibility works.

Let me pick an example to explain how Google Baseline fails on its promises: CSS Cascade Layers.

Cascade Layers are part of Google Baseline. According to the new browser support box on MDN, this feature is “widely supported” with the note added: Baseline is determined by this web feature being supported on the current and the previous major versions of major browsers.

The link “See full compatibility” brings you to the browser compatibility table.

This table is very informative. It tells you that Cascade Layers were shipped in the listed browsers last year. Firefox was the first (of the listed browsers) to ship support on 2022-02-08. Samsung Internet was the last (of the listed browsers) to ship support on 2022-08-08.

We have learned that all major browser engines and evergreen browsers support it since August 2022. That is nine months ago.

Reality check: Usage-relative browser support

Unfortunately, MDN does not tell you the market share of these browsers. And MDN does not tell you about other browsers that are actually used.

The entry for @layer on Can I Use shows the same browser support data but puts them into perspective. If you select “Usage relative”, you get a stacked column chart with browser versions that support and do not support the feature.

Can I Use also calculates a total percent based on the global browser market share. That percent value is a staggering 90.19%. That means Cascade Layers work for 9 out of 10 of your website visitors. They do not work for one visitor out of 10. This important fact is hidden behind the “widely supported” verdict of Baseline.

Where does this discrepancy stem from?

MDN only states which browser versions started supporting the feature and when. It does not show market shares of the versions that do support and those that do not. This is unique to the “Usage relative” view of Can I Use.

Evergreen browsers auto-update every month, but some people are still stuck on old versions that do not support Cascade Layers. Three examples:

• 2.11% of all web users are using Chrome < 99.
• 0.95% are using desktop Safari < 15.4 and 1.74% are using mobile Safari < 15.4.
• 0.65% are using Firefox < 97.

There is another reason why the MDN support table suggests 100% support while the actual global support is rather 90.19%: The MDN table omits browsers with a small market share.

One of these is UC Browser for Android published by the Chinese Alibaba Group. This browser has a global market share of 0.95%. It is based on a fork of Chromium 78. You heard right, in May 2023, UC Browser is stuck on a browser engine that was released in October 2019! Web developers in the Western world mostly ignore UC Browser, but it is still popular in India, Indonesia and China. These countries have a combined population of almost 3.1 billion people.

While the individual percent values are rather small, they add up to 9.81%.

This example illustrates that web authors need to check browser support for a feature and join it with browser market share data to get a clear impression. Can I Use is still the best tool for that. The simplistic “widely supported” claim of Baseline is not accurate.

Assessing practical backward compatibility

The most important question is not how many browsers support the feature but what happens in browsers that do not support it.

This is where we need to examine the feature itself, Cascade Layers. Here is a simple but common example (see also Chris Coyier’s basic use case for Cascade Layers):

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<title>Cascade Layers example</title>
<style>
@layer bootstrap, my-own-styles;

@import url("https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/css/bootstrap.min.css") layer(bootstrap);

@layer my-own-styles {
  button {
    font-size: 2rem;
  }
}
</style>
</head>
<body>
<p>
<button class="btn btn-primary">Activate me!</button>
</p>
</body>
</html>

This document imports the Bootstrap library and assigns it to the layer bootstrap. We want to make sure that our own code always overwrites Bootstrap, without waging specificity wars against Bootstrap selectors.

So we assign our code to the my-own-styles layer and set the layer order so that my-own-styles is more important than bootstrap.

Voilà, the button has a font-size of 2rem even though Bootstrap sets a font-size for .btn, which has a higher specificity than button. Without Cascade Layers, Bootstrap would win the specificity conflict. (We could use the same selector as Bootstrap in our code, .btn. But this is what Cascade Layers make obsolete.)

Now for the interesting part: How do older browsers without Cascade Layers support deal with this code?

The answer is, these browsers do not recognize @layer and @import with layer() and therefore ignore the code. They do not download Bootstrap either.

Is this good or bad? It is rather good! They do not understand this newer syntax and continue parsing un-layered styles, if any.

When using Cascade Layers, it makes sense to assign most of your styles to a layer. If you do so, these styles are not applied in 9.81% of the browsers.

Unfortunately, it hard to use Cascade Layers in a backward-compatible way. As Miriam Suzanne wrote:

Since layers are intended as foundational building blocks of an entire CSS architecture, it is difficult to imagine building manual fallbacks in the same way you might for other CSS features. The fallbacks would likely involve duplicating large sections of code, with different selectors to manage cascade layering — or providing a much simpler fallback stylesheet.

Stephanie Eckles wrote:

With new CSS features, we can often begin using them as a progressive enhancement. For example, with properties like aspect-ratio or selectors like :is(), we can use @supports to include new features while supporting fallbacks. Or, sometimes features can be added, and graceful degradation is acceptable without a comparable fallback.

However, cascade layers are such an all-encompassing change that it will be difficult to start moving to use them until a polyfill is available. Unfortunately, @supports doesn’t currently work with at-rules, and even if it did, it would not be entirely sufficient for cascade layers since unlayered styles always win over layered ones.

To recap:

• We cannot use Cascade Layers as an enhancement step (Progressive Enhancement).
• There is no practical fallback possible without rewriting all layered styles (Graceful Degradation).
• It is not possible to detect support for Cascade Layers in old browsers using HTML or CSS alone. It is possible to detect support for Cascade Layers using JavaScript by checking for window.CSSLayerBlockRule.
• There is no easy way to serve Cascade Layer code to new browsers and legacy code to old browsers.
• The good news is, there is a PostCSS-based Cascade Layers polyfill that transforms @layer code into backward-compatible code. As you might expect, the polyfill has several limitations.

After having investigated the specific feature and the behavior of old browsers, we can ask the questions that Baseline tries to answer:

Is it okay to start using the feature? – It depends on the site you are building, your users and how you use the feature. If you are building a site for the global audience and find Cascade Layers useful, you should try whether the polyfill works on your code. If you are building for a limited audience with newer browsers, like for a corporate intranet, you can start using Cascade Layers without safeguards in place.

Is it safe to use? – Technically yes, since old browsers will ignore the new syntax because their CSS parsers are forwards-compatible. But you should not serve a site without styles to almost 10% of the users. Many sites are still readable without styles. But styles are not just decoration and veneer, they facilitate readability, usability, accessibility and interactivity. You should provide at least some basic styles to all browsers.

Summary

Google Baseline does not answer crucial browser compatibility questions. Baseline merely states that the latest version and the last but one version of certain evergreen browsers support a feature interoperably. This is good to know, but not enough to use the feature on your site in a safe manner.

My fear is that Google’s Baseline initiative oversimplifies the discourse on browser support. Web authors will see “widely supported”, all-green checkmarks and alleged 100% browser support and use the feature without further examination. Web publishers will say “we require Baseline” without realizing that it means they only support two-month-old evergreen browsers plus the latest Safari.

Coming back to the pursued benefits:

When planning a project, rather than needing to list specific browser versions, you can set a requirement to use features that are part of Baseline.

That is not enough. Please perform a market analysis to find out the browser usage in your audience. Then decide which browsers you want to support and find out how. Use Progressive Enhancement when planning a project.

When publishing a library, you can help potential users understand support of features used (and therefore whether it is safe to use on their site) by declaring support for Baseline.

That is not enough. Please make deliberate browser support decisions and document them. Please state the individual browser versions the library requires. Please state how the library behaves in older browsers. Please use feature detection in your library. Please define your own baseline and state it in a machine-readable way using Browserslist.

When writing a tutorial, you can tell readers that everything described is in Baseline. Your reader then knows this is a solution they can incorporate into a project.

That is not enough. Please explain how old browsers deal with the new code. Please explain how to use the feature as an enhancement or in a backward-compatible way.

With new web technology features being shipped every four weeks, web authors need better practical guidance. I agree we need to unify and simplify browser support information.

A better browser support box should center on practical and safe usage. A concise text should answer these questions: What is the percentage of users with browsers supporting the feature? How do old browsers deal with the feature? Can it be used as an enhancement? How to detect the feature? How to develop a fallback? Do polyfills exist?

I believe this will enable web authors to develop modern sites using the latest browser features without impairing compatibility.