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:
- Newly available – a feature is supported by the latest versions of all core browsers
- Widely available – a feature has been supported across browsers for at least 30 months
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:
Progressive enhancement
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.
Access for all
Underlying our browser support policy are two foundational principles:
- Website content and core functionality should be accessible to everyone.
- It’s okay for websites to look different in different browsers.
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.
