Page MenuHomePhabricator

Refresh target browser support for MW, dropping less-used browsers from Grade A to Grade C
Closed, DeclinedPublic0 Estimated Story Points


Right now our Grade A support is, in descending order of amount of traffic to Wikimedia sites:

BrowserPlatform%age of trafficGrade A support target%age of this UA served at Grade A
Chrome *Mobile27.80%current + previous79.7%
Safari **Mobile24.58%6.1+100%
Chrome ***Desktop19.83%current + previous84.3%
Internet ExplorerDesktop5.44%1180.6%
Firefox~Both5.34%current + previous78.28%
EdgeDesktop1.70%"TBD" (current + previous)?

* – Includes Samsung Internet (3.05%)
** – Includes Chrome Mobile iOS, Firefox iOS, Mobile Safari UI/WKWebView, Apple Mail (total 1.79%)
*** – Includes Yandex Browser (0.23%)

Browsers ignored: UC Browser (0.35%), Opera Mini (0.27%), Amazon Silk (0.11%), IE Mobile (0.08%)

Proposed new policy:

BrowserPlatformProposed new Grade A target%age of this UA served at Grade AΔNotes
ChromeMobilecurrent + two previous82.10%+3%Reflecting actual practice
SafariMobilecurrent + two previous97.97%-2%Drops support to Safari 10+
ChromeDesktopcurrent + two previous84.94%+5%Reflecting actual practice
Internet ExplorerDesktop11100%No change
Firefox~Bothcurrent + two previous78.5%+0.2%Reflecting actual practice
EdgeDesktopcurrent + two previous100%N/AEstablish actual practice
SafariDesktopcurrent + two previous87.97%-12%Drop support to Safari 10+
OperaDesktopcurrent + two previous96.5%N/ANo change, but aligned with Chrome
AndroidMobile4.1+91.6%No change

Ideally we'd be able to go with "current + two previous" for all browsers, but that'd mean (a) moving IE to Grade C support entirely as Edge has replaced it, and (b) leaving a lot of stock Android users in the lurch.

Event Timeline

Our current support is primarily driven by the ability to use certain capabilities on the web platform. Our exceptions are

  1. to force Grade C in limited cases where a browser we support has this capability but we believe the user experience would be better in Grade C mode (and for unsupported browsers we think would have a better chance at not breaking under Grade C).
  2. to only classify as Grade A and C the browsers we offer active development and testing support for (the rest being Grade X / whatever happens).

Are there additional capabilities we can and want to require with this proposal that we don't require today? (In other words moving browsers from A to C.)

Or is this about changing the support and testing we offer (and document) without changing the grade these browsers are effectively at. (In other words, moving browsers from/to Grade X).

I think the latter but wanted to confirm before I act on that assumption :)

On reflection, I'm not sure whether I mean Grade C or Grade X.

The main trigger for me writing this up (other than feeling like it's been a while since we've done this, and that we've not even established a support level for Edge yet) is that there's a lot of crufty CSS that it'd be nice to clean up. But getting rid of supporting code means intentionally breaking them, so it might be better to intentionally bump them down to Grade C?

Fly by note: Something about Firefox ESR. Effectively supported already, but perhaps worth formalising?

Have you considered stalling this task? Do default Android browsers and IE11 share the same codes that other browsers (mobile and/or desktop) do?

I don't like the idea of downgrading support of Safari 9, 10, and 11 based on popularity. OTOH, I like the idea of supporting "current + two previous" versions of Chrome, Firefox, Edge, and Opera as "grade A" for the sake of tech flow.

If stalling the task is impossible, then why not create subtasks, especially for separate, individual browsers?

The following related tasks are more specific and have been resolved since and/or are currently actively discussed instead. Consider participating there instead.

I'm closing this for now, but I agree that we if there are things we want to cut sooner than IE11/ES<6, or things not already cut by those proposals we may want to use separate tasks for those with specific capabilities or maintenance costs associated with them (as for the above).

The principal thing this task was driving at beyond IE11/ES6 was support for archaïc Safari versions, which are not captured in any of those tasks.