Android 2.0+ on desktop question has been split out into T249788.

It seems like PNG support should be completely unnecessary in any kind of JS application given we don't run JS here. If we do want to continue supporting background-size on IE8 as a compromise we could limit this fallback to modules added via addModuleStyles.

I would like to second this opinion. I believe that we originally had these PNG fallbacks because some of the Modern (Grade A) Browsers at the time needed it. If there are no Grade A browsers that require PNG fallbacks, we should probably remove this feature.

@Volker_E Thanks. I've moved it to Phase 3 for you. (Resourcing isn't a concern for policy updates, see RFC/Process for details.)

I've added analytics pageview and edit schema data to the task description:

Task description (T248061#UQ0_80)

Internet Explorer 8 users at 17 million page views per month (out of 18.8 billion), which is about 0.1%. […]

IE 8 Page views (turnilo.wikimedia.org)		Total page views
17.5m between 15 March and 15 April 2020		18.8b between 15 March and 15 April 2020

…

IE 8 Page views (analytics.wikimedia.org)
0.06% during first week of April (1% of 5.9%)

January 2020 saw 273 loads of the editor in IE 8 (action=edit, wikitext editor), of which 5 edits were submitted.

P10994 EditAttemptStep data from IE8 (2020-01)

1	# krinkle@stat1005.eqiad.wmnet
2	# hive> SELECT CONCAT('2020-0', month) AS ymonth, event.action, COUNT(*) FROM event.EditAttemptStep WHERE year=2020 AND month=1 AND useragent.browser_family='IE' AND useragent.browser_major='8' GROUP BY month, event.action ORDER BY ymonth ASC LIMIT 10;
3
4	ymonth action _c2
5	2020-01 init 273
6	2020-01 saveAttempt 5
7	…

In T248061#6037518, @Niedzielski wrote:

Developing for IE 8 […] clients is not something I've been explicitly testing myself and, if our formal QA process does perform these tests at any point, I am unaware of it. […]

mw:Compatibility only mentions active testing for Grade A. To my knowledge that is still the case today. I could be wrong, but I don't think we have products where QA testing includes the Basic experience? Assuming not, then this lack of active testing isn't relevant to IE 8 and isn't something we stopped doing. It would apply equally to IE 10 or any non-latest version of Chrome or Firefox.

Our only commitment to "Basic" is to respond to end-user reports; And to consider it proactively during a few high-impact decisions such as Forward secrecy of our web browser traffic over TLS, or when adopting a CSS or HTML feature for the first time in a skin or primary content. (Hence we shipped html5shiv in 2017 prior to unblocking <figure>.)

According to the definition, "basic" support means:

In the front-end this means content is presented in a readable manner, […]

I don't wish to overstate the problem but it can be costly to guarantee even readability. For example, a verbose menu that is normally hidden may be fully expanded on these devices and cause page content to appear quite disarranged. […]

I agree the scenario you describe is likely to be missed in our current testing, and I think that more generally applies to Grade C browsers. It might even apply to how the page behaves in the latest browsers prior to the JS successfully arriving (or failing). The main idea behind Basic is that it's based on pure CSS and HTML, which is pretty consistent across browsers. If it works in a modern browser, it likely works everywhere, which is why we've not invested in its testing.

The above isn't meant to sound disapproving. I'm supportive/neutral on this RFC. I don't see any technical problems, and in terms of audience impact, I've provided the numbers for Product to make a decision. I just wanted to clarify the background around the lack of test coverage. It's soemething I'd love to see expand more generally, but it's an understandable trade-off.

In the task description, @Volker wrote:

I'm convinced we shouldn't kid ourselves into thinking that basic support is still really provided, it's okayish to browse desktop Wikipedia with some limitations, but all things editing or more complex interaction products are already severely limited and in parts completely broken. I also know no current team that is testing against those browsers.

Homepage to our “basically supported” software for IE 8 (layout issue has been fixed after sharing here, but speaks to lack of testing point above).	Homepage in ja (upper)	Same with Translation extension (lower)

Per the above, I've removed this as current testing practices is not in question for Grade C browsers. Features are as lacking in IE8 as for other Grade C browsers. We don't test in Grade C browsers. Stuff that users control (templates) may be broken in Grade C, they are also sometimes broken on mobile (half our audience). We help the community fix them if we find out about it. And for our own stuff, similarly, we only fix stuff in Grade C when it is brought to us. IE8 isn't special in that regard. It's expected that we'll find one or two oddities if we proactively look for it.

+1, from the perspective of helping hosts of a mediawiki farm, few users and our core offerings don’t work properly.

Progressing further in the process.

Stakeholders having been reached out to are:

• Readers Web (on this tak), as maintainers of our primary skins. Sounds supportive so far. @Jdlrobson Can you or Olga confirm this?
• Product management (via @Volker_E). I've provided various analytics data above. Still awaiting a response.
• CPT (via @tstarling). Can you or Cindy sign off from your team's perspective and/or let us know if you need more time, have questions, or want more information.
• Third party farms:
  • Hello Welt: @Osnard
  • Wikia: @TK-999
  • ShoutWiki: @ashley
  • WikiHow (via myself, by e-mail):
• TechCom has taken a look and sees no technical concerns.

For myself, I note that I think this decision should mainly be influenced by affected users (in numbers, not percentages) and by the understood cost for supporting them. Hence the analytics data I provided above. I think it's too easy and not in our mission's spirit to make this decision based on 0.1% sounding small or IE8 being an old browser. In practice, our commitment to Grade C is quite low anyhow, and the cost to maintaining support quite low as well given pure HTML/CSS generally "just works". We only think about it during major arch decisions and otherwise only respond to bug reports. There's afaik never been proactive testing on a regular basis, regarless of which Grade C browser.

No objections from my side. For BlueSpice we only support down to IE 11 anyways. And even this one is going to be dropped soon.

Thanks for reaching out! I've confirmed that IE 8 has no support status on either of our wiki products so there are no objections from our side.

In T248061#6087556, @Krinkle wrote:

[…]
WikiHow (via myself, by e-mail):

I've heard back. It looks like they would like to keep basic reading if possible, but also recognise that it's not large enough portion of their traffic to likely justify investments any time soon to help keep that working. Overall, no blocking concerns.

No objections here either. I think given the current data that supporting removal is a good next step forward from a product perspective. The rates of usage are low and I think this decision would better reflect the current reality.

As @Volker_E mentioned before, this also does not mean that the current experience would break further, but it would absolve developers and product teams of the responsibility to QA, create fallbacks for the browser, and triage bugs and tasks which would generally be low priority and rarely touched, which is a situation that I already believe reflects the current reality at least somewhat.

I would also like to point to some of the findings in T250385: Estimate readership from Internet Explorer 8:

• Overall usage of IE8 (percentage of overall pageviews) : 0.21%
• None of the wikis have IE8 usage close to 0.5%
• Webrequest data from Mar 29,30,31 for IE8 in Italy suggests that the original data issue is being caused due to bot traffic mistakenly identified as user traffic - a few inconsistencies in the data make us think that this is also the case for some other wikis with higher than average raters (Russian, for example), which would bring down the actual rates even lower.

Given the above, I think the audience is small enough to allow us to go forward.

After consulting with the other Product leaders, we have no objections to moving forward with removing IE8 from basic support (and the related T248062 task).

In T248061#6131089, @ovasileva wrote:y.

As @Volker_E mentioned before, this also does not mean that the current experience would break further, […]

This is incorrect. Keeping what we have today, is the very definition of basic support, which this RFC proposes to discontinue.

In terms of explicit cost on a daily or weekly basis from product engineers, this is very low right now. By now we generally instinctively know the limitations of the browsers we support and what capabilities we can assume for the basic experience. As such, this cost mostly comes in the form of two other things instead:

• 1) Roads not taken. We avoid exploring ambitous new ideas or optimisations in our code bases that we know would be infeasible or impossible to make work on current Grade C browsers. Similarly, if there is a cheap way to do something with an expensive fallback, or a slightly less cheap way to do something that requires no fallback, we're likely to do the latter without even thinking about it. I would expect these to happen at a small scale all the time.
• 2) Infrastructure support. The design and content presentation developed in the skin is reachable by end-users because they build on or get transported by our infrastructure. This is continuously upgraded, reviewed and maintained. For example, Core Platform work in MediaWiki core, Performance work in the RL/JS pipeline, SRE work on the CDN caching layers, HTTPS connection certificates, DNS resolution for hostnames, etc.

The latter regularly make decisions based on our current support matrix. If IE8 is not supported, then within a few weeks it would not be strange for IE8 users to be unable to connect to wikipedia.org (as if the website doesn't exist).

In T248061#6131089, @ovasileva wrote:

[…] it would absolve developers and product teams of the responsibility to QA, create fallbacks for the browser, and triage bugs and tasks which would generally be low priority and rarely touched, which is a situation that I already believe reflects the current reality at least somewhat.

Aside from triaging bugs and determining if something is an unbreak now, the above is already the status quo. Proactive testing here so far (afaik) has never been considered worth the cost. Absence of this already reflects the current reality of IE8 being at basic support.

We know that the basic technologies we use for this experience are mature, stable and generally work the same across all browsers. On rare occasion something does come up through a bug report, if it's critical, we fix it. That's all that basic support means. (We don't create fallbacks or perform regular QA for IE10 or iOS 5, either).

We do make sure that domain names, routing of internet traffic to our data centers, HTTPS connections, and HTML processing, and the JS pipeline are all set up in a way that doesn't crash or otherwise prevent delivery of the content to these browsers. This infrastructure support can be seen as "boolean", that is, it either works at every level, or the user gets nothing at all.

Is it expected that users of IE8 have access to some foundation web properties in some form?

Just double checking to make sure we're all on the same page. Last I spoke to @Volker_E, he was to reach out to @ovasileva and decide, based on the nuance above, which way they wanted this RFC to go. I let Volker know that Tech Com's position here was just that we wanted them to understand the nuance and technical implications, not to steer the RFC one way or another. That decision remains with them.

Followed up with @Volker_E and had another discussion. Given the low usage and the caveat that at least some of that amount of that is bots, I think it is still okay to go ahead with removal.

Is it expected that users of IE8 have access to some foundation web properties in some form?

Per my discussions with Volker, no. IE8 users may be totally unable to reach our sites next week, and that's OK. Of course, my hope is that they will still able to use the site in a minimal capacity, but if not, we will no longer expend effort to support them.

In T248061#6185930, @kaldari wrote:

Is it expected that users of IE8 have access to some foundation web properties in some form?

Of course, my hope is that they will still able to use the site in a minimal capacity, but if not, we will no longer expend effort to support them.

The approval of this RFC will be the signal to all engineers, SRE, and community folks that IE8 will no longer be supported at Grade C. Most or all of the potential gains that can be had from this, however small, generally happen all in rapid succession at that point – just as as happened when we did so for IE6-7, Firefox 2, Opera 9 etc.

@Krinkle Given that the release cut branch for REL1_35 is around the corner (July 13th), it seems preferable to wait for the final go until then to me.

I moved this to last call last week. The last call period will end June 24th. It makes sense to wait until release 1.35 is out to start making changes.

Per today's TechCom meeting, this RFC is approved as proposed and discussed. Compatibility with IE8 can be dropped from master once 1.35 has been branched. This means that compatibility is retained for the 1.35 released, compatibility for the Wikimedia sites is dropped as soon as 1.35 has been branched (probably some time in July).

Change 609502 had a related patch set uploaded (by Ladsgroup; owner: Ladsgroup):
[mediawiki/core@master] Drop html5shiv

https://gerrit.wikimedia.org/r/609502

Change 609502 merged by jenkins-bot:
[mediawiki/core@master] Drop html5shiv

https://gerrit.wikimedia.org/r/609502

Compatibility matrix template has been officially bumped.

Just thought I'll post this link for posterity: https://www.mediawiki.org/w/index.php?title=Template:Compatibility_browser&diff=3995422&oldid=3958720

Change 623885 had a related patch set uploaded (by Arlolra; owner: Arlolra):
[mediawiki/services/parsoid@master] Drop html5shiv

https://gerrit.wikimedia.org/r/623885

Change 623885 merged by jenkins-bot:
[mediawiki/services/parsoid@master] Drop html5shiv

https://gerrit.wikimedia.org/r/623885

Change 698277 had a related patch set uploaded (by Fomafix; author: Fomafix):

[mediawiki/core@master] Remove workarounds for IE8 from TOC style

https://gerrit.wikimedia.org/r/698277

Change 698277 merged by jenkins-bot:

[mediawiki/core@master] Remove workarounds for IE8 from TOC style

https://gerrit.wikimedia.org/r/698277