Page MenuHomePhabricator

RFC: Remove IE 8 from basic support
Closed, ResolvedPublic

Description

  • Affected components: MediaWiki core, skins and extensions.

Motivation

  • Improve the user experience by making pages load slightly faster and use less bandwidth, because we'd send less CSS code down the wire.
  • Take away maintenance-burden of writing fallback CSS for newer CSS features not supported in IE8. The effort spent here is a waste of our limited resources.
  • Unlock use of newer CSS features that do not have a fallback and thus cannot be safely used today.

Features we would no longer consider optional or need fallbacks for:

  • box-shadow
  • RGBA (Wikimedia deployed), HSL and HSLA color values
  • opacity (without needing -ms-filter, Wikimedia deployed)!
  • SVG background icons (without generating PNG fallbacks, also reducing related CSS size massively). See also T248062, T159738.
    • We're currently automatically generating PNG fallbacks in OOUI for all icons, like .oo-ui-icon-alert, .mw-ui-icon-alert:before { background-image: url(load.php?modules=oojs-ui-core.icons&image=alert&format=rasterized&skin=vector&version=ytdfw); (example). This happens even for VE, where the PNGs are just unused (given it requires IE11).

Features we could start using:

  • background-size (possibly interface-critical, think icon-only interaction elements),
  • transform,
  • transform-origin (deployed),

Proposal

I'm proposing to remove IE 8 from “Basic” in the browser support matrix.

This would be effective in MediaWiki 1.36, released later this year.

Statistics

Grade A support for IE 8 was dropped 5 years ago in MediaWiki 1.27 (T118303).

Removing IE 8 from Grade C support was previously proposed 3 years ago, but declined at the time (T136203).

In the meantime we have Internet Explorer 8 users down to 17 million page views per month (out of 18.8 billion), which is about 0.1%. The exact percentage varies by the week. Generally between 0.03% - 0.10% (analytics.wikimedai.org).

For comparison, Firefox 2 (has no Grade C support), actuallys appear to have a higher percentage of use, at 0.2%-0.4% in all weeks of 2020 so far.

IE 8 Page views (turnilo.wikimedia.org [restricted])Total page views
17.5m between 15 March and 15 April 202018.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%)

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

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
4ymonth action _c2
52020-01 init 273
6 2020-01 saveAttempt 5
7

Impact

Taking away the Grade C status would not necessarily further break the experience, we would only take away maintenance-burden from implementors, that is a waste of our limited resources. It would remain unknowingly supported similar to Firefox 2.

The biggest positive impact are some CSS support improvements like removing PNG fallbacks for SVGs for those browsers, exemplified at T248062.
I see this as chance to improve experience for vast majority of our users by reducing CSS code sent down the wire, while the negative impact of icon only elements missing icons should be within still somewhat acceptable reading/browsing experience.

Other features

These are also unsupported in IE8, but are not unlocked by this RFC due to other older browsers not yet supporting them either:

  • Grid layout, still not a thing – that's blocked by IE 9.
  • Flexbox – blocked by IE 9
  • Using rem units. This would be a very nice benefit, but even with IE 8 out of the picture not yet in reach as long we support Firefox <= 3.6 in basic.
  • transition and animation – blocked by IE 9
  • hyphens – blocked by IE 9
See also:

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

I'm sorry to add a "me too" comment but I wanted to express agreement for this RFC beyond the award. Developing for IE 8 / Android 2.0+ 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.

I think this discussion is relevant for Desktop Improvements and broadly. It would be helpful to me if the the support matrix could be reevaluated and formalized prior to significant Desktop Improvements development occurring and its deployment on the test wikis, both for resourcing and risk mitigation. A good chunk of the Desktop Improvements Project is pure HTML and CSS (no JS), so these decisions can be impactful.

According to the definition, "basic" support means:

In the front-end this means content is presented in a readable manner, and to some extent user actions can be performed, but these browsers do not get JavaScript features.

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. At what point is jumbled content unreadable? It's not always clear and diminishing the readability requirements for "basic" would probably make its distinction less valuable.

Krinkle assigned this task to Volker_E.Apr 7 2020, 7:05 PM
Izno added a subscriber: Izno.Apr 7 2020, 8:29 PM

@Jdlrobson Probably the better task to associate here is T21719: HTML5 features (tracking)?

Nirmos added a subscriber: Nirmos.Apr 7 2020, 10:00 PM
Volker_E updated the task description. (Show Details)Apr 8 2020, 5:53 PM
Volker_E updated the task description. (Show Details)Apr 8 2020, 9:35 PM
Johan added a subscriber: Johan.Apr 9 2020, 5:27 AM

This has been marked for inclusion in Tech News, but it doesn't seem like a decision has been taken. Is this at the stage where feedback from the wider community would be useful?

Volker_E updated the task description. (Show Details)

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

Volker_E renamed this task from RFC: Remove IE 8 and Android 2.0+ from basic support to RFC: Remove IE 8 from basic support.Apr 9 2020, 7:33 AM
kaldari added a subscriber: kaldari.EditedApr 9 2020, 6:44 PM

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.

Krinkle moved this task from P1: Define to P3: Explore on the TechCom-RFC board.Apr 9 2020, 9:58 PM

@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.)

Krinkle updated the task description. (Show Details)Apr 15 2020, 10:03 PM
Krinkle added a comment.EditedApr 15 2020, 10:06 PM

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 202018.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.

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
4ymonth action _c2
52020-01 init 273
6 2020-01 saveAttempt 5
7

Krinkle added a comment.EditedApr 16 2020, 12:08 AM

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.

Volker_E updated the task description. (Show Details)Apr 16 2020, 4:41 AM
Volker_E updated the task description. (Show Details)Apr 16 2020, 5:48 AM

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

Krinkle moved this task from P3: Explore to P4: Tune on the TechCom-RFC board.EditedApr 28 2020, 2:06 AM
Krinkle added subscribers: TK-999, Osnard, ashley.

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:
  • 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.

Krinkle updated the task description. (Show Details)Apr 29 2020, 9:36 PM
Krinkle updated the task description. (Show Details)May 1 2020, 1:55 AM

[…]
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).

Krinkle added a comment.EditedMay 27 2020, 8:06 PM

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).

[…] 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.

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.

Milimetric added a comment.EditedJun 17 2020, 8:52 PM

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).

DannyS712 updated the task description. (Show Details)Jun 26 2020, 10:49 PM

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

Volker_E closed this task as Resolved.Jul 28 2020, 2:46 AM

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 ambitious 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).

Thanks for the separation of support costs.
From my experience looking at the front-end/UI side I can't fully agree with sentiment taken above, specifically in 1) – leaving 2) the general support side on HTTPS, HTML processing behind here. First off newcomer volunteers, but also senior devs are repeatedly taking certain technological standard features for granted the wider they are supported and (I) find themselves(/myself) forgetting about the support quirks of an 11 year old browser. We might brush this off as acceptable visual breakages fair for basic support. Yet I see a major gap between the front-end/UI definition of basic interface support and the other, above mentioned infrastructure support. Have filed T258993 to look into clarifying basic support language.
Ignoring, or forgetting about the edges goes hand-in-hand with general usage, industry support and popularity of it among our users – aside of it being painful to provide workarounds contradicting W3 standards. We might not see a lot of those issue surface in MediaWiki core as there are very few front-end heavy interfaces. But thinking that its only roads not taken would be misleading. See usage of [[ https://codesearch.wmcloud.org/core/?q=opacity%3A&i=nope&files=&repos= | opacity ]] or Flexbox in core without fallbacks implemented.

A related, very important upcoming question is Vue.js support. Vue.js v2 is not supporting IE8. This will most probably going to affect MW core too.

Altogether I'm very happy that we've agreed that it's time to say goodbye in IE 8 support and go one step further into a more empowered future (highly subjective POV) – thanks to TechCom, specifically @Krinkle in fledging this out, and Product management with @kaldari and @ovasileva diving in and backing this given the numbers and information provided.

Compatibility matrix template has been officially bumped.

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