Here are the new HTML/CSS properties when going from Chrome 49/Safari 10/Firefox 49 to last 7 years' versions.

Unprefixed

• CSS writing-mode property
• CSS :any-link selector (-moz- no longer needed, -webkit- still needed)
• CSS Filter Effects
• Intrinsic & Extrinsic Sizing (partial, only -webkit- unprefixed only, -moz- still needed)
• CSS3 Multiple column layout (partial)

Full support

• :placeholder-shown CSS pseudo-class (unprefixed)
• CSS text-orientation (-webkit- prefix for Safari)
• ::placeholder CSS pseudo-element (unprefixed)
• CSS background-blend-mode
• Pattern attribute for input fields
• Form validation
• HTTP/2 protocol
• :indeterminate CSS pseudo-class
• CSS3 Border images
• CSS.supports() API
• :default CSS pseudo-class
• :in-range and :out-of-range CSS pseudo-classes
• focusin & focusout events
• CSS font-stretch
• Download attribute
• Subresource Integrity
• Fetch
• Upgrade Insecure Requests
• CSS font-variant-numeric
• #rrggbbaa hex color notation
• Animated PNG (APNG)
• Minimum length attribute for input fields
• rel=noopener
• SPDY protocol
• "once" event listener option
• KeyboardEvent.key
• CSS justify-content: space-evenly
• CSS Grid Layout (level 1)
• :focus-within CSS pseudo-class

Partial support

• Resource Timing (basic support)
• Opus audio format
• relList (DOMTokenList)
• Scroll methods on elements (scroll, scrollTo, scrollBy)
• system-ui value for font-family
• FLAC audio format

#rrggbbaa hex color notation is very useful as it is easier to create translucent colors which having to resort to rgba(). Let's say if you want to create green color with 60% opacity, you only need to type #00800099 instead of rgba(0, 128, 0, 0.6). It uses nine bytes instead of 20, so it can use less data. Additionally #RGBA is even smaller, at only 5 bytes.

CSS Grid Layout (level 1) is very useful as it is easier for designers to layout the user interface and make it responsive for mobile devices.

CSS font-variant-numeric could be useful as it is easier to read numeric tables with tabular numerics.

Why 7 years and not 6 or 8? Why introduce a timeframe?

Timeframe is useful as market share for older versions of browsers drop as time progress.

7 years is a magic timeframe for companies, such that Google supports "7 years of software updates" for Pixel 8 series phones.

Last year, Grade A support for browsers except Safari and Android have restated to last 3 years' versions.

Additionally, MediaWiki would feature new CSS features as time progresses.

I agree it would be ideal to move to a rolling window like Grade A for simplicity, but in practice Grade C is meant to capture a much wider net of readers which doesn't always correspond to a specific timeframe. Like I suggested in T380344#10349484, if there's no specific product/feature that needs this version bump we should probably wait to see how T367821 develops because it might make 7 years not even applicable.

I clarified that TLS 1.3 supports Safari macOS 12.1+ (on macOS Mojave and later) and Safari iOS 12.2+.

https://caniuse.com/tls1-3

I mentioned that CSS Grid Layout and #rrggbbaa/#rgba hex notation need this version bump. Both are very useful.

I have updated browser versions to be within 7 years.

I have added affected operating systems

I have previously discussed something similar to this task with Krinkle at https://www.mediawiki.org/wiki/Topic:Tvju6hdstykonsbj (section title "Process to change compatibility" on Talk:Compatibility for if/when Flow dies on MW wiki). I don't know if Krinkle ever followed up on that discussion as they suggested they would.

As said by @Bugreporter at T380344#10339262, Safari doesn't use the "three years' prior revisions" rule for Modern (Grade A) support because the "Safari [on] iOS [cannot] be upgraded individually."

Safari (macOS, iOS): 11 [previous 7 years' versions]

Don't know why changing Safari's Basic (Grade C) support is still proposed in this task.

I think that, as a matter of mission and principle, we should try to support browsers longer than commercial sites do. For example, if the industry standard is 7 years, then we should aim for 10.

But if a browser is extremely unpopular, then we shouldn't invest time in supporting it. For example, while I give 10 years as a possible support length, if almost nobody is using a 9-year-old version of Firefox, and supporting that would require investing a significant amount of dev time, then I don't think it makes sense for us to make that extra effort.

@WhatamIdoing I'd agree about an industry standard if there were one. Most companies don't really care about anything else than their technological choice impacting their sales (if at all).
To my knowledge and during my tenure at the Foundation, we (the volunteers and the Foundation) have always been very careful to not exclude anyone without important reason, besides some edge case technical stupidities (captcha anyone?).
What is happening with basic support is, that it should provide a tested reading capabilities experience: "…content is presented in a readable manner, and all page and account actions are discoverable and work".
Web standards are always changing and expanding and making supporting these capabilities in older browsers possible, but at a cost: To make the page slower, the user-interface harder to develop in the 99% other browsers.

One of several examples which is currently blocked by our Basic capabilities browser group is getting rid of a costly in-performant workaround for icons in T383943: Remove Grade C support for Firefox 49-52. Without the workaround the icons in the vanishing browser are rendered as black squares. From a product perspective it could be discussed, if this still does match the definition above. Or if reading the article and seeing menu entries labels for page and account actions besides black squares are sufficient to get a satisfying basic experience.

Apart from that is the costly assurance of testing the site in 10 year old browsers, the amount of browsers to test in increases with the boundary dating back every year. Which results another hidden cost.

So a reasonable boundary like 7 years is actually helping the vast majority of our users with higher performance and better tested interfaces while barely leaving anyone completely lost. And by and large I think you were adhering to this take too…?!

The TLS change doesn't seem to move forward fast enough to make a difference T367821: Discovery: Deprecation of TLS 1.2

Reorientation of task

The change looks like it maybe misses the point of the task orientation. Now it appears to be framed as set everything to 2018 (or higher per Edge), while the actual interest of the task is "make it rolling at 7 years". If that's not the desire, that should be returned somewhere to the description or name of the task, just for clarity's sake.

CanIUse browser percentages

Let's try to use our own statistics in traffic if we can, which are public at https://analytics.wikimedia.org/dashboards/browsers . (We don't know the source of CanIUse data, do we? If it's StatCounter, that has known issues.) Legoktm made (at my request) a little consolidator at https://steve-adder.toolforge.org/ , but you can pull the data directly if you want there instead. Our browser stats indicate

• Chrome is very popular in that range, Chrome 49-71: 1.35%, about 0.5% on mobile and the remainder on desktop. It's distributed fairly evenly in the range of versions. I'd guess this is either an excessive tail of hardware in developing countries... or bots. (Though we have no particular reason to believe this is fake traffic.)
• Firefox is in the 0.005% range, which is negligible.
• Chrome WebView in that range doesn't measure.
• In contrast to Chrome, Safari actually has pretty small numbers in the relevant range. Safari 10-13 hits only about 0.1%. (Chrome and Firefox iOS add only a bit to that number.)

The last time older versions of Chrome, Firefox, and Safari were dropped from Basic, the current baseline versions (49, 49, 10) were all about 8 years old, so from that standpoint it might make sense to target the last 8 years' versions. That would drop about 0.916% of page views from Grade C to Grade X.

Here are some more stats. The first number in each cell is the page views for that browser/year, the second number is cumulative for all previous cells in the column. Compiled using https://steve-adder.toolforge.org.

At the very least, we could adopt a ten-year Basic support target for Chrome, Firefox, and Safari, which would mean no immediate practical changes, but come the new year the oldest versions would automatically fall out of Basic.

It looks like that would affect about 1 in 230 users. Do we know if there any geographical implications for this (e.g., most of them are in developing countries, where access to newer hardware might be difficult)?

In T380576#12185752, @WhatamIdoing wrote:

It looks like that would affect about 1 in 230 users. Do we know if there any geographical implications for this (e.g., most of them are in developing countries, where access to newer hardware might be difficult)?

I'm not sure where you're getting the "1 in 230 users" figure -- could you clarify?

It's worth noting that dropping browsers from Basic doesn't directly change anything about the user experience on those browsers; it's really just a documentation change, that allows features not available in those older browser versions to be put into use. Only after those features go into widespread use -- which could still take some time -- would you start to see negative effects, and even then many of said features may fail gracefully on older browsers, or at least not completely break the user experience. That's not to say those impacts don't matter, because of course they do. I'm just trying to put it in perspective.

I wouldn't be surprised if average browser age somewhat correlates with geography, but I don't know any specifics. Certainly something worth considering.

As I've said, though, we could simply set a 10-year support target, which would cause exactly *zero* immediate support changes.

Ah, never mind, the "1 in 230" is from the 0.433% in my table above. Never mind :)

Personally, I'd argue for an 8-, 9-, or 10-year support target. That would keep the page views leaving Basic below 0.1% (0.916%, 0.433%, or 0% respectively).

In T380576#12186068, @Mr._Starfleet_Command wrote:

Personally, I'd argue for an 8-, 9-, or 10-year support target. That would keep the page views leaving Basic below 0.1% (0.916%, 0.433%, or 0% respectively).

I did say in T434028#12185711 that I have no opinions on the 9-year target. Nonetheless, I'm thinking that 8-year target would be anymore very short. Also, the 10-year target would be kinda more beneficial than the other two options.

However, I'm afraid that targets fixed by years are too absolute for me to support tremendously. Rather I would treat them like potential rules of thumb... or there should be some other rule of thumb, especially for any of browsers to comply with.

In T380576#12186094, @gh87 wrote:

I'm afraid that targets fixed by years are too absolute for me to support tremendously. Rather I would treat them like potential rules of thumb...

Well, as I said in the task description for T433929:

Exceptions could be made as needed, of course, e.g. dropping versions ahead of time or keeping them longer than usual.

Also, keep in mind we already do this "fixed by years" approach for Chrome, Edge, and Firefox for Modern support -- do you think we should undo that too? (Not trying to be rhetorical, just legitimately curious what you think and what your reasoning is :) )

10 years has a nice round-number sound to it. But there should be some cost-benefit approach to any specific decision about how much work we could do to fix a problem that only affects a tiny number of users. So perhaps 10 years is a "goal" or a "hope" or a "usual practice", rather than a commitment or contract?

(Yes, 1 in 230 = 0.433%.)

In T380576#12193861, @WhatamIdoing wrote:

...there should be some cost-benefit approach to any specific decision about how much work we could do to fix a problem that only affects a tiny number of users.

By "how much work we could do to fix a problem that only affects a tiny number of users" are you referring to the work it takes to fix bugs affecting older devices, or the work to drop support from older devices? (If the latter, there really is none -- just a documentation change.)

So perhaps 10 years is a "goal" or a "hope" or a "usual practice", rather than a commitment or contract?

I accept it wouldn't be an absolute commitment, but it could be the default, that we can opt out of as needed. As I said above,

Exceptions could be made as needed, of course, e.g. dropping versions ahead of time or keeping them longer than usual.

@Izno You're right, I'd like to differentiate two issues:

• a general policy agreement (taking the best parts of this task and clarify arguments for a rolling target with sign-off from stakeholders): in my honest opinion better off as separate task
• an update to the several-years unchanged browser support statement, which would be immediately impactful for product and user performance reasons: this task!

@WhatamIdoing Just to clarify, from a MediaWiki platform perspective, browser support decisions are based on several factors. To paraphrase what Krinkle laid out in the conversation with @Izno years ago, the typical questions/criteria include:

[…] monthly page views, edits, ability to upgrade (e.g. which OS is typically associated with that browser, could the user upgrade?), cost/benefit in terms of engineering.

That engineering cost isn't limited to fixing browser-specific bugs. It also includes ongoing testing and quality assurance work, maintaining compatible tooling, and avoiding performance or maintenance costs that affect the 99%+ of users on newer browsers.

Security can override all of these considerations. T367821 is a coming good example: if a browser can no longer securely access Wikimedia infrastructure at all, then continuing to support it in current MediaWiki versions becomes irrelevant.

There is also an important distinction between basic support (Grade C) and unknown support (Grade X).
You said:

But there should be some cost-benefit approach to any specific decision about how much work we could do to fix a problem that only affects a tiny number of users.

That's essentially what I see a task like this as doing.

Moving a browser from basic support doesn't mean deliberately making the sites inaccessible to it (exception security requirements above)**. It means we stop promising to support and test that browser, and we –or also volunteer developers– no longer require our tooling or developers to accomodate it.

A Chrome 49 user, for example, may therefore continue to see and use the sites much as before, perhaps with little or no immediate difference. We simply no longer will be held accountable to that experience or spend engineering resources preserving it.

From a lead engineer level I will say, that 8 years were already a very long support period. If it were entirely my decision, I would probably target around 5 years for maintaining and testing basic browser capabilities. A user –or especially an IT department– using browser that hasn't been updated in 5(!) years has much larger security and compatibility concerns than MediaWiki alone could ever solve and is in serious troubles.

Given our experience over the past 10+ years, 7 years seems like a reasonable compromise when balancing usage, upgradeability, engineering cost, performance, QA, volunteer burden, and security.

The important principle is quite simple to my conviction: we shouldn't promise a level of browser support that we cannot realistically maintain. It's better to set a clear, sustainable expectation than to overpromise and underdeliver.

Since T344791, users can't login on Chrome 51-66. Per https://www.mediawiki.org/wiki/Compatibility#Grade_C:

Grade C browsers must receive the core functionality of the MediaWiki platform.... all page and account actions [must be] discoverable and [must] work...

Therefore, we must at the very least raise the Basic requirement to Chrome 67. And, if we also set a support target, that should be 7 or 8 years, which should also apply to Firefox (barely adds to the page-view share, not to mention they already share a Modern target of 3 years) -- Safari/iOS can be handled separately if needed.

For clarity -- what sort of signoff do we need from WMF? I assume it's MediaWiki-Core-Platform-Team, like for Grade A changes, but confirmation would be nice.

In T380576#12196630, @Volker_E wrote:

@Izno You're right, I'd like to differentiate two issues:

• a general policy agreement (taking the best parts of this task and clarify arguments for a rolling target with sign-off from stakeholders): in my honest opinion better off as separate task
• an update to the several-years unchanged browser support statement, which would be immediately impactful for product and user performance reasons: this task!

Per the task description, it seems this task is actually the first of those two (and has been from the start). Not saying it's the best way to go about it, but it seems that was the intent here.

In T380576#12197096, @Mr._Starfleet_Command wrote:

[...] we must at the very least raise the Basic requirement to Chrome 67. And, if we also set a support target, that should be 7 or 8 years, which should also apply to Firefox (barely adds to the page-view share, not to mention they already share a Modern target of 3 years)

You can bump up the Basic (Grade C) requirement to Chrome 67, but that doesn't mean the Basic support "should be 7 or 8 years", does it?

(EDIT:) Almost forgot: Firefox versions older than 49 are considered Grade X, including 45 ESR and 48. Firefox 78 ESR is still receiving Basic support. (Source: Wikipedia)

(EDIT #2) Firefox ESR 78 makes up 0.005% viewership

In T380576#12197133, @gh87 wrote:

You can bump up the Basic (Grade C) requirement to Chrome 67, but that doesn't mean the Basic support "should be 7 or 8 years", does it?

Read my comment more closely: I said that if we were to set a support target then it should be 7 or 8 years. Chrome 67 was from 2018, which was 8 years ago; that's just math.

Chrome 67 was released at the end of May 2018, which is 8.2 years ago, i.e., more than 8 years ago; that's just math. If the rule is 8 years ago, then both 67 and 68 are older than 8 years.

In T380576#12204517, @WhatamIdoing wrote:

Chrome 67 was released at the end of May 2018, which is 8.2 years ago, i.e., more than 8 years ago; that's just math. If the rule is 8 years ago, then both 67 and 68 are older than 8 years.

It depends on how you interpret an X-years rule: If it's 8 years, does that mean 11 August 2026 - 8 years = 11 August 2018 and you take the last version after then (Chrome 69) or the last version before then (Chrome 68)? Or, is it 2026 - 8 years = 2018 and you take the first version from 2018 (Chrome 64) or the last version from 2017 (Chrome 63)? That's why I say "7 or 8 years", it would be one or the other depending on which approach we use.

Do you know how we currently handle the 3-years target for Chrome/Edge/Firefox Modern support?

In T380576#12204661, @Mr._Starfleet_Command wrote:

It depends on how you interpret an X-years rule...

@WhatamIdoing Turns out you were right, the correct interpretation is "X years ago from where we are in the year right now." With this in mind, I've updated the table in the task description.

Let's assume for the moment that we *do* want to set rolling support targets. In that case, Chrome and Firefox (and eventually Edge) should share a target, both for simplicity and because they share a Modern target. Let's also assume that we don't want to drop more than 1% of page views out of Basic. Then, as I said above:

Since T344791, users can't login on Chrome 51-66. Per https://www.mediawiki.org/wiki/Compatibility#Grade_C:

Grade C browsers must receive the core functionality of the MediaWiki platform.... all page and account actions [must be] discoverable and [must] work...

Therefore, we must at the very least raise the Basic requirement to Chrome 67.

Taking all this together, we arrive at an 8 year target for Chrome and Firefox, while Safari could have an 8, 9, or 10 year target, all of which would meet the criteria I've outlined. I'd suggest an 8-year target, as it would be simplest, matching Chrome and Firefox, but the other two options would be fine as well.

Now, the only large assumption I've made so far is that we indeed want to set rolling support targets. I've already explained the various benefits this would have, so let me first clarify what this would NOT involve:

• Completely or partially blocking access to those browsers: In fact, there would be no immediate changes whatsoever on said browsers. The main degradation that would eventually occur is that CSS would begin to use features that aren't supported in those browsers, but it is unlikely that even that would seriously disrupt the experience, except perhaps in the oldest of them after several more years.
• UA sniffing of any kind: This proposal would NOT involve UA sniffing -- it's simply a documentation/configuration change.
• Absolute, unbreakable rules: These targets would be, well, targets. As I've said, "Exceptions could be made as needed... e.g. dropping versions ahead of time or keeping them longer than usual."

And now, the benefits:

Benefits of setting rolling support targets for Basic support:

• Less arguing about when this or that browser version should be dropped
• A gradual stream of newly-available CSS features rather than occasional "bursts"
• Very little need to discuss and plan for dropping old browsers, which means old browsers continue to lose Basic support even if devs are busy with other things.

Furthermore, rolling support targets *are already used* for Modern support for Chrome, Edge, and Firefox, so there is precedent too.

But, if people really don't want rolling support targets, we should at least raise the Basic requirement for Chrome to version 67, for the reason I explained above.

I've more or less said this all before, but not all composed together into a (hopefully) convincing argument, as I've tried to do here.

Last but not least, I reiterate:

[W]hat sort of signoff do we need from WMF? I assume it's MediaWiki-Core-Platform-Team, like for Grade A changes, but confirmation would be nice.

Since no one responded to this question, I've added that tag to this task. @Krinkle, is this correct? PS Also I'd love to hear your (dis)agreement with me on this issue.

Side-note: in my "first-choice" outcome as I laid out above, browserslist-config-wikimedia's basic.json would look something like this:

[
	"Chrome > 0, Edge >= 79, Firefox > 0, Safari > 0, iOS > 0, ChromeAndroid > 0 and last 8 years",
	"Android >= 5"
]