You can view RSS feeds from my friends and colleagues.
Just recently, some front-end code Clearleft delivered to a client was making its way through acceptance testing. We were slightly surprised to discover that their standards required our code to be supported by the two latest versions of web browsers. And then we realised we didn’t have a browser support policy of our own – something we set about rectifying.
When considering browser versions, we were fairly sure our client didn’t mean, for example, versions 124 and 125 of Chrome (released on 16 April and 14 May 2024 respectively). Instead their support standard would most likely be harking back to the days when Internet Explorer was a thing, and major browsers were updated once a year at best. To put this in context, the final version of Internet Explorer shipped in 2013.
It’s at this point we noted that Clearleft didn’t have a written browser support policy to counter or complement that of our clients. We probably did in the dim and distant past, but in recent years we’ve just built accessible, progressively enhanced websites without feeling the need to codify what that means. For the sake of professionalism and good client relationships, we decided to rectify that.
But where to start? Using browser versions clearly doesn’t make any sense, so what do we turn to instead? As it turned out, Jeremy had already nailed it in a recent blog post. We wanted a browser support policy that would focus on outcomes for the user. Rather than being fixated on specific browsers, we needed to consider capabilities, using the mindset that sees modern coding use feature detection in preference to browser detection. It turns out there’s an initiative for that.
The Baseline initiative is a joint effort by Google, Microsoft, Apple, and Mozilla to categorise browser support for web standards. Baseline provides clear information about which web standards features are ready to use in websites. It designates new features into two categories:
We use the Baseline project to determine which browser features to use in production. If a feature is widely available according to Baseline, we can use it.
Quoting directly from our browser support policy:
If a feature is newly available, we might still use it, but we’ll ask a follow-up question:
“Can this feature be used as a progressive enhancement?”
In other words, will using this feature harm browsers that don’t support it? If a newly-available feature can be used as a progressive enhancement, we might well use it. If not, we’ll wait until the feature becomes widely available and choose a different method in the meantime.
This approach restricts usage of new features to nice-to-have additions rather than mission-critical requirements. But it also means we don’t necessarily have to wait for every browser to support a feature before using it.
Underlying our browser support policy are two foundational principles:
If content is unreadable in some browsers, that’s a bug that we will fix. If content is displayed slightly differently in some browsers, we consider that to be a facet of the web, not a bug. This means that there will sometimes be subtle visual and functional differences from browser to browser. We deem this acceptable provided that content and core functionality are unaffected.
We think this the right approach to browser support, and it’s something we believe the whole industry should follow in principle. To that end we’ve made our browser support policy available under a Creative Commons license, meaning you can use it for your own purposes if you find it helpful.
Originally published on the Clearleft blog.
I seem to have left pieces of myself scattered around the internet. This is my attempt to pull some of those pieces together.