Standardising browser support across Guardian web projects/sites

[coldlink]

The Problem

When working on a web application project it is useful to know which browsers should be targeted as a baseline to know which feature we should be targeting (e.g. for JS, CSS), and maintaining a consistent baseline experience when a user navigates between projects, e.g. a journey from dotcom to identity to manage.

@paddyo @SiAdcock and I came across an issue in Chromium causing a bug in Source, which is due to be (likely) fixed in Chrome 86 (after 6 years), however we decided it would be best to workaround regardless of the update as the Source guidelines says it support Chrome 77+.

From this it was discovered that different projects use different (or no official!) browser targets.

For example The Guardian help page has one set of browsers, DCR has a slightly different set, and so does Source. In Identity for our Gateway project, we don't any specific browser support targets except having functionality work in IE11.

Especially thinking we're likely to be sharing more code between projects in the future, and are already doing so using Source components, it would be nice if there was once place or a way to determine exactly a set of browsers that should be supported, as well as knowing a baseline for any new projects being created and worked on. So I thought this would be a useful discussion to open.

@JamieB-gu helpfully mentioned that some projects have very different requirements. While most web projects (e.g. DCR/Identity/support-frontend) probably have quite a similar list of browsers. Apps-Rendering however is very different: it currently supports iOS 12+ webviews (essentially Safari 12+ but without service workers), and Android 5+ webviews (which is approximately modern Chrome for Android). So it may be worth focusing specifically for web projects rather than a grand unified set?

Possible solutions

1. A possible solution would be to use a browserlist file/config/something along those lines that could be shared between projects, and consumed by tools e.g. babel, eslint, stylelint

2. A single source of truth support table, possibly on the help page or updating the recommendations

[sndrs]

this sounds like a great idea to me 👍

browserslist allows you create a shared config which seems a good start. its something we could point help to and maybe even that help page? (might be a bit too technical).

and +1 for all web properties having the same baseline

[SiAdcock]

This is a great proposal and something that is badly needed. A conversation about this pops up every once in a while and most of the time there is no resolution.

Prior work

• @sndrs created an awesome spreadsheet based on Google Analytics that reports how many visitors we receive from each browser, and then calculates a minimum supported version for each browser based on 0.5% cut-off. I think the spreadsheet was lost when he left the company, but maybe we can recreate something similar?
• the recommended browsers page is badly out of date. While technically we can and do try to support these browsers, there is no way we can test every version of Chrome since v49... we rely on bug reports from users. We can't justifiably call these browsers "recommended" if we don't test our changes in all of them. Also the copy on this page is confusing and would benefit from a re-write.
• In frontend, we have 2 bundles: "core" and "modern" (sometimes called "standard" and "enhanced"). These provide different experiences, and the experience that gets served depends on the capabilities of a user's browser, in short whether the browser supports features such as localStorage. This is called cutting the mustard. From what I understand in DCR we now do mustard cutting on <script type="module">, but it would be useful to understand what that means from a user experience perspective. It might also help to understand which browsers get which experience.

Bigger picture

I might be an outlier here, but what I would ultimately like to see is some bigger picture thinking. We don't have a definition of things like "support", "fully support" or "full experience". I think these definitions would help us to understand what we ought to do (devs and user help) when a bug report comes in, or how to go about testing our changes.

I'm also not sure that it's satisfactory for devs to unilaterally decide a set of browsers to support. I think this needs some steer from product too, with input from user help.

===

UPDATE: reading back, this is not a useful message. Apologies. What it needs are:

Questions for the group

• Am I alone in thinking that browser support requires more strategic thinking? I don't want this comment to put a spanner in the works, especially if there's improvements we can make straight away.
• Do we agree in general that we need steer from product / input from user help when determining which browsers to support, whether there will different "levels" of support and experience and what that would entail? If so, I can try to assemble a squad to take care of this 👨‍🏭👷‍♀️👩‍💻👨‍🔬

[SiAdcock]

There has been some related discussion on the Dotcom channel

[JamieB-gu]

One thing that potentially complicates this is the level of support offered by your device vendor, since users are typically accessing our products through a proxy (iOS, Android, web browser). If Apple drops support for iOS 12, Microsoft drops support for IE11, Samsung drops support for a Galaxy S10, to what extent do we still have a responsibility (or the ability and resources) to make sure our products work on those platforms?

[SiAdcock]

It's an interesting question. However, I do think we should go by proportion of our users who are using those products. If a vendor takes a misguided decision to deprecate or drop support for a popular product, I think the number of users who are using it is still the signal we should be following. We support readers, not products 😊

[coldlink]

This is such a broad topic, but in my opinion quite important. From the discussions above, I think there are 4 main goals we're trying to answer here:

1. What does "browser support" mean as a term? Is there a way we can codify this?
2. What are the actual minimum browser versions that we will "support" once the above question has been answered?
3. How can we test/confirm that each feature/fix/etc. that we release works on all of the browsers specified?
4. How can we do this across teams so that we all have the same base level of "support"?

[JamieB-gu]

2. What are the actual minimum browser versions that we will "support" once the above question has been answered?]

There may be three categories of platform here:

a) Web (dotcom, support-frontend, identity-frontend etc.): all major browsers back to version X.
b) Apps (iOS, Android, Editions): Safari version X, Chrome version Y.
c) Tools (composer, fronts etc.): Recent Chrome and Firefox?

(@jonathonherbert may be able to confirm the support list for (c)?)

3. How can we test/confirm that each feature/fix/etc. that we release works on all of the browsers specified?

4. How can we do this across teams so that we all have the same base level of "support"?

Automated tooling for browser testing might be big enough to warrant its own topic in the CS Infra discussions. I think we've used a few different solutions in the past: Selenium and Browserstack on RR, Cypress and PRBuilds on dotcom etc. It would be nice to get some best practices established, although worth noting that different projects may have slightly different requirements: e.g. apps and dotcom may only need screenshotting capabilities, whereas RR is more interested in user interaction/journeys.

[JamieB-gu]

@jacobwinch @jorgeazevedo may have some thoughts on the above, particularly given the work they've been doing live testing and screenshotting recently?

[mchv]

Excellent discussion. Fully agree with the need of consistency between our different websites and apps. As a general principle we aim for accessibility so having a common standard will be extremely helpful. However I think we should not encourage readers to use software/hardware which could compromise their safety and/or require amount of work absolutely disproportionate for us and not sustainable on the long term.

Concrete examples:

• TLS 1.1 support. We recently remove TLS 1.1 because it is fundamentally insecure.
• iPad Air 1. This device is not supported anymore by Apple since 2019 and has only 1gb of ram. Loading an image of good quality on such low memory is tricky. Efforts we put supporting such old device are not sustainable, as few number of users using such a device will continue to decline. So it his great if we could make our apps work on such device and avoid usage of resource in general, but if the efforts are huge and prevent us to spend more time on improving the app overall it is not a great use of our limited number of devs.