(NOTE)
Current policy: <https://www.mediawiki.org/wiki/Compatibility#Browsers>
* 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 ([[ https://codesearch.wmflabs.org/deployed/?q=%3A%20rgba%5C(&i=nope&files=&repos= | Wikimedia deployed ]]), HSL and HSLA color values
* `opacity` (without needing `-ms-filter`, [[ https://codesearch.wmflabs.org/deployed/?q=-ms-filter&i=nope&files=&repos= | 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);` ([[ https://en.wikipedia.beta.wmflabs.org/wiki/Transcluded_page?quicksurvey=true&debug=true | 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` ([[ https://codesearch.wmflabs.org/deployed/?q=transform%5C-origin%5C%3A&i=nope&files=&repos= | deployed ]]),
* .. and basically **[[ https://docs.microsoft.com/en-us/previous-versions/ff468705(v=msdn.10) | everything else new in IE 9 ]]**, specifically [[ https://docs.microsoft.com/en-us/previous-versions/hh393506(v=msdn.10)?redirectedfrom=MSDN#_css_fonts | CSS ]].
-------
### Proposal
I'm proposing to **remove IE 8 from “Basic” in the [[ https://www.mediawiki.org/wiki/Compatibility#Browser_support_matrix | browser support matrix ]]**.
This would be effective in MediaWiki 1.35, 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% ([[ https://analytics.wikimedia.org/dashboards/browsers/#desktop-site-by-browser/browser-family-and-major-tabular-view | 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
|--|--|--
| {F31758323 height=100} | {F31758325 height=50} | {F31758327 height=80}
| 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)
|--
| {F31758329}
| 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.
{P10994}
##### Status quo
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.
| {F31691353} | {F31720769} | {F31720773}
| 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)
##### 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 [[ https://caniuse.com/#search=rem | as long we support Firefox <= 3.6 in basic ]].
* `transition` and `animation` – blocked by IE 9
* `hyphens` – blocked by IE 9
##### See also:
* {T232563}
* {T136203}
* {T118303}