Note:

• Chrome and Firefox use last 3 year version rule. Currently Safari does not use such rule, probably because Safari in iOS can not be upgraded individually.
• The Grade A and Grade C defined are normative only.
  • It does not define which browser will get JavaScript (which is detected via feature check in startup module)
  • Non-JS features must work in all Grade C browsers, and JS features must work in Grade A browsers (but might work in some Grade C ones)
• Using newer JS features is not only blocked by this requirement, but also blocked by T277675: Add native support for ES2016-ES2017 to the minifier. Currently, only features up to ES7 can be used in Wikimedia code, where all Grade A browsers at least supports ES8.

However for Safari, we will drop support for version <14 completely once T367821: Discovery: Deprecation of TLS 1.2 is resolved.

https://analytics.wikimedia.org/dashboards/browsers/#all-sites-by-browser/browser-family-and-major-hierarchical-view

• Safari iOS 14: 0.38% of Safari iOS users (0.08% of all)
• Safari iOS 12: 0.5% of Safari iOS users (0.1% of all)
• Safari iOS 11, 13: <0.1% of Safari iOS users (<0.02% of all)

• Safari 14: 2% of Safari users (0.072% of all)
• Safari 13: 0.86% of Safari users (0.032% of all)
• Safari 12: 0.16% of Safari users (0.006% of all)
• Safari 11: 0.4% of Safari users (0.014% of all)

Total Safari (macOS, iOS) 11-14: 0.324% of all pageviews

Historically, we've raised the browser support requirements based on a feature we want to use that we think is worth the trade-off. GZWDer is correct that the auto-upgrade features of Chromium- and Firefox-based desktop browsers have meant that we've changed to a rolling three-(ish)-year window, and that doing this for mobile-based devices like iOS Safari and Android Chrome would be a more aggressive change.

Is there a specific feature that is being held back from production by raising iOS and desktop Safari to 15+ (i.e., every other browser including Android 5 support it)?

https://gitlab.wikimedia.org/repos/ci-tools/browserslist-config-wikimedia is where the code version of our standard lives, but let's decide first before writing patches. :-)

• Android 5, released in 2014, supports up to Chrome 95 (released in 2021) (3 years old) as well as the latest version of Firefox (2024)
• iOS 14, released in 2020, supports only Safari 14, also released in 2020.

Chrome and Firefox for Android can be updated through Play Store.

I agree that if there is no specific need for this version bump, it's probably best to wait on T367821 since that will have the same effect on the current matrix.

I'm pretty sure dropping Safari 10 would arguably give us level 1 of CSS Grid which I feel like is a pretty compelling factor, though that's only if you ignore how it's a non-default feature flag for Firefox up to 51 and Chrome up to 56. I'm not sure what the precedent is on whether non-default feature flags count as "support".

In T380344#10349484, @CCiufo-WMF wrote:

I agree that if there is no specific need for this version bump, it's probably best to wait on T367821 since that will have the same effect on the current matrix.

if that's the case, shall this task on Safari versions be stalled then?

In T380344#10340438, @Jdforrester-WMF wrote:

Historically, we've raised the browser support requirements based on a feature we want to use that we think is worth the trade-off. […]

Indeed. This proposal is essentially a duplicate of T429706 which is the way we would normally do this.

In T395347#12037702, @Krinkle wrote:

I've analyzed ES2019 as well, and that requires no support changes compared to today beyond Safari 12, basically the same as this task for ES2018 — except for the lookbehind feature that Apple didn't ship until Safari 16.4.

I recommend the following: […]

We can revisit RegExp lookbehind next year as part of T429706: Raise Grade A JavaScript requirement from ES2019 to ES2020 (ECMAScript 11).

In T380344#12185066, @Krinkle wrote:

In T380344#10340438, @Jdforrester-WMF wrote:

Historically, we've raised the browser support requirements based on a feature we want to use that we think is worth the trade-off. […]

Indeed. This proposal is essentially a duplicate of T429706 which is the way we would normally do this.

Bear in mind that we don't do it that way for *all* the browsers - Chrome, Edge, and Firefox have a 3-year support target, so we don't need to consider/discuss moving older versions out of Modern, we've agreed that it should happen every year. Why not do the same thing with Safari? It doesn't need to be a 3-year target, of course, but an X-year target, whatever we pick for X.

In T433929, @Mr._Starfleet_Command wrote:

I believe it would be better if clear support targets were included for all browsers, both for Basic and Modern support. (Exceptions could be made as needed, of course, e.g. dropping versions ahead of time or keeping them longer than usual.)

[...]

Safari 12.1, the new Modern Safari baseline, is 7 years old, so we could target the last 7 years' versions of Safari for Modern support. However, when the previous Modern baseline (Safari 11) was set, it was only 5 years old, so we could target the last 5 years' versions instead, which would put us around Safari 14. Or, we could aim for 3 years, to match the existing Modern target for Chrome, Edge, and Firefox, which would put us around Safari 16.

Shall we not treat iOS Safari and macOS Safari as the same please?

• Safari iOS 15: 1.0% of Safari iOS users (0.20% of all)

• Safari 15: 1.7% of Safari users (<0.1% of all)

More importantly, I'm thinking the ones managing Pageviews stats might prioritize stats of the mobile web more than desktop or mobile app.

In T380344#10340438, @Jdforrester-WMF wrote:

[...] the auto-upgrade features of Chromium- and Firefox-based desktop browsers have meant that we've changed to a rolling three-(ish)-year window, and that doing this for mobile-based devices like iOS Safari and Android Chrome would be a more aggressive change.

Sorry, missed this bit. I don't quite understand - I get that a longer window may be needed for Safari/etc., but can't it still be quantified as a certain number of years, even if more than 3?

(For example, we could even set Safari's Modern support target at 7 years, which would mean no drop in support for now, but come next year we could then straight-away drop Safari 12 rather than discussing it again and again. See?)

Shall this task be stalled then? I just now created T434032: Drop Modern (Grade A) support for Safari 12.

Statistics
Safari 12-15 makes up 0.370% of all WMF page views.

Uhh... iOS 15 makes up 0.277%: https://steve-adder.toolforge.org/?wanted=Mobile+Safari&wanted=Mobile+Safari+UI%2FWKWebView&wanted=Safari&start=15&end=15

Older iOS versions, especially iOS 12, have much smaller percentage than iOS 15