Contrib.social

[policy, no patch] Define usage heuristics for browser support

Open on Drupal.org →
Created on 9 September 2019, about 5 years ago
Updated 5 April 2024, 8 months ago

Problem/Motivation

#2390621: [policy, no patch] Update Drupal's browser support policy → defines a rolling browser support policy, where we commit to supporting current (or current + previous etc.) versions of specific browsers.

What the policy does not do is provide a clear way to add or remove browsers from the supported list.

Examples would be:

1. A new mobile browser that's increasing in popularity

2. An old desktop browser that has gone past EOL.

On #2390621: [policy, no patch] Update Drupal's browser support policy → we agreed that 1% is a good threshold to add or remove a browser from support, however there is more work to do:

Proposed resolution

Use statcounter and caniuse as the canonical source for browser statistics.

https://caniuse.com/usage-table
https://gs.statcounter.com/

Also refer to the two-yearly screenreader survey conducted by webaim. https://webaim.org/projects/screenreadersurvey10/ - a survey specifically of screenreader users.

TODO: find a good source for geographical browser usage, in case a specific browser is very highly used in particular countries (previously this has included Opera mobile in Africa, and older versions of IE in China).

If a supported browser is on course to drop below 1% global usage by the time of a major release and the webaim survey shows either non-significant usage or a solid downward trend, then drop support for the browser in advance of the major release date so that dependencies and core code can operate based on the browsers we will actually support for the duration of the release.

If an unsupported browser is on course to increase above 1% global usage, has significant (>30%?) market share in particular geographic areas, or is disproportionately and steadily or increasingly used by screenreaders, open an issue to add it to the list of supported browsers.

2. Define what threshold we use to drop a browser. On the previous issue we agreed 1% was a good rule of thumb. We may also want to take into account the webaim survey in case a browser is disproportionately used by screenreader users. If a browser is disproprtionately included in the webaim survey, we should evalute:

a. is this because of a specific technical reason that makes it better for accessibility?
b. Is usage on an obvious downwards or upwards trajectory?

3. Browser support determines which bug reports we accept for our own code, but it is also determines (and is to some extent determined by when they drop support) which third party libraries we adopt. Given that we have to make decisions about third party libraries months or years in advance of major releases, can we agree to look at trend data for browser support as well as the raw libraries?

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

🌱 Plan
Status

Needs review

Version

11.0 🔥

Component
Other  →

Last updated about 6 hours ago

Created by

🇬🇧United Kingdom catch

Live updates comments and jobs are added and updated live.
  • Needs frontend framework manager review

    Used to alert the fron-tend framework manager core committer(s) that a front-end focused issue significantly impacts (or has the potential to impact) multiple subsystems or represents a significant change or addition in architecture or public APIs, and their signoff is needed (see the governance policy for more information). If an issue significantly impacts only one subsystem, use Needs subsystem maintainer review instead, and make sure the issue component is set to the correct subsystem.

  • Needs product manager review

    It is used to alert the product manager core committer(s) that an issue represents a significant new feature, UI change, or change to the "user experience" of Drupal, and their signoff is needed. If an issue significantly affects the usability of Drupal, use Needs usability review instead (see the governance policy draft for more information).

  • JavaScript

    Affects the content, performance, or handling of Javascript.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment over 1 year ago →
    🇬🇧United Kingdom catch
  • Comment over 1 year ago →
    🇬🇧United Kingdom catch

    This only really becomes critical when we want to add or drop support for a browser, in between, we forget about it hence lack of activity here. Next time adding or dropping a browser comes up I think we should postpone that on this issue, but for now moving to major.

  • Status changed to Needs review over 1 year ago
  • Comment over 1 year ago →
    🇬🇧United Kingdom catch
  • Comment 8 months ago →
    🇬🇧United Kingdom catch

    there have been two webaim surveys since this was last updated, so linking the new one. https://webaim.org/projects/screenreadersurvey10/

    We didn't make any changes to the supported browsers for Drupal 11 because there were no pressing trends (and we already dropped IE), but it would be nice to get this closed out so if something does get notably more or less popular in the next couple of years, we've got some guidelines on how to approach it.

  • Comment 8 months ago →
    🇳🇿New Zealand quietone

    I gather this will be a new policy page in the ' Core change policies' → guide.

    My first pass at that text is

    Introduction

    Browser support determines which bug reports are accepted. It also determines which third party libraries are adopted and influences when those libraries are removed. Trend data is used because the decision about third party libraries is made months or years in advance of a major release.

    Dropping a browser

    Support for a browser is dropped when the following conditions are met.

    1. The browser is on course to drop below 1% global usage by the time of a major release.
    2. The browser has insignificant screen reader usage or a solid downward usage trend as shown by the latest webaim screen reader survey.
    3. If the browser is disproportionally included in the lastest webaim screen reader survey, then it should not be providing a specific technical reason that makes it better for accessibility.

    Support is removed in advance of the next major release. This allows dependencies and core code to operate on the browsers that will be supported for the duration of that release.

    Adding a browser

    A browser is added when either of the  following conditions are met.

    • It is on course to increase above 1% global usage, has significant (>30%?) market share in particular geographic areas.
    • It is disproportionately and steadily or increasingly used by screenreaders, 
    • If the browser is disproportionally included in the lastest webaim screen reader survey, then it should be providing a specific technical reason that makes it better for accessibility.

    References

    The following are used to evaluation browser adoption.

    • statcounter
    • caniuse
    • lastest webaim screenreader survey
    • Hopefully, add a good source for geographical browser usage, in case a specific browser is very highly used in particular countries.
  • Comment 8 months ago →
    🇷🇺Russia Chi

    There are two points that need to be taken into considerations.
    1. We live in epoch of "always green" browsers. Vendors continuously push new browser releases. It would be hard to manually evaluate available browsers each major release of Drupal.
    2. There is a variety of chrome based browsers. We probably need to establish the support policy based on on the version of Chromium engine.

    That was already mentioned in #7. I think the evaluation of browser adoption can be done through through browser list.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024