Are browser support policies dead?
With the apparent news that Microsoft is giving up on EdgeHTML and moving to a Chromium-based rendering engine, it’s tempting to think that we no longer need to maintain browser support or testing policies.
After all, if there are only a couple of variants of rendering engine to support, do we really need to have an explicit policy?
Publicly available browser support policies are much less visible than about ten years ago. Much of this is likely due to consolidation of support for web standards, making it easier to create sites that work cross-browser without the need for explicit treatment.
But that doesn’t mean it’s a given that we ‘support’ a browser. A browser support policy isn’t for the development team (although we are one of the stakeholders) - it’s for end users, customers, customer support, sales, partners, the list goes on.
So even if you have a very simple policy in practice - for example, a kiosk app that runs only on a specific version of Chrome - it’s important to be explicit and transparent about what that support is and what it means to support it.
Up to now, to take advantage of the features of ES2015 and beyond, we’ve been transpiling to ES5 for all browsers alike. Now, Babel, Webpack and similar tools are starting to provide better support for delivering conditional bundles, so that older browsers will continue to receive ES5 bundles and new browsers can take advantage of native feature support. Many teams have already been doing much the same when ‘polyfilling’ web platform features.
If anything, browser support documents now need to encompass more: devices, browsers, features, offline expectations, you name it. This goes way beyond ‘browser support’, but still serves the same purpose: setting expectations for how your product operates, and where you will spend time on bug fixes and improvements.
Do you have an explicit browser support policy? Does it need an update or rewrite? Sounds like a fun winter holiday exercise, right?…
All the best,