If I understand correctly, there is a plethora of HTML5-related tasks that would require us to completely drop support for IE8 in order to be solved. I could not find such a task, so I'm creating this.
Description
Description
Related Objects
Related Objects
- Mentioned In
- T248061: RFC: Remove IE 8 from basic support
T178398: Use semantic HTML5 <main> tag for primary page content
T178356: Raise Grade A JavaScript requirement from ES5 (2009) to ES6 (2015) - Mentioned Here
- T147199: Removing support for DES-CBC3-SHA TLS cipher (drops IE8-on-XP support)
T25932: Allow use of semantic HTML5 elements in wikitext
T122965: Provide a way to support HTML5 elements in browsers that don't support it and don't have JS shipped, like IE8 and below
Event Timeline
Comment Actions
meh, 'require'...
As I have stated before in one of those tickets, we could easily load a html5shiv with a conditional comment JS. See also: T122965
So I would say that it is not blocked on IE8
Comment Actions
See this page for details about our level of support for IE 8:
https://www.mediawiki.org/wiki/Compatibility#Browsers
We have in fact already dropped support for Modern mode ("Grade A") for IE 6, IE 7 and IE 8. However we do still keep support for Basic access ("Grade C") for old IE. This is in my opinion essential to our mission and should not be taken lightly.
Under the current support we may already adopt HTML5 features in cases where the fallback is acceptable for Basic mode. Remember that HTML (in most cases) has no concept of user-facing failure. So any HTML element can be used safely regardless of it being "supported" by that browser. It just means they won't be styled by default. For things like inline elements used in the content and meta data, this is perfectly acceptable already. They'll simply render as plain text.
We already support many HTML5 elements in wikitext output.
So far we've rejected changes that adopt HTML5 elements for the overall skin layout (e.g. content wrapper, sidebar, footer). Especially we had trouble justifying the added value. There are more arguments I won't repeat here, but for example with regards to accessibility, we already set attributes that provide the same semantic value.
Without a clear added value the end-user, I don't imagine elements like <nav> or <aside> being used anytime soon in MediaWiki core, or MediaWiki skins used by Wikimedia.
Comment Actions
See also T25932: Allow use of semantic HTML5 elements in wikitext for exhaustive support table.
Comment Actions
I think we shouldn't do this for at least a few more years. Wikimedia wikis aim to provide the "sum of human knowledge" to "every single human being", and without a very good reason (e.g. when we effectively dropped support for IE 6, because it can't handle any secure HTTPS encryption methods) I don't think we should lock out those who, for whatever reason, are stuck on an old browser.
Grace C support means "basic support". The fact that we make an effort to support IE 8 doesn't mean we can't use any new features that it doesn't support. This shouldn't be a blocker for T25932, for example, as browser should just ignore unsupported elements (and display their contents).
Comment Actions
I'm declining this task in its current form. Support for IE8 has already been lowered to Grade C, which essentially means "It just works"" due to use of stable web technologies.
Removing IE8 support would mean very little in practice (given it's not explicitly on any whitelist). When this task was initially filed there were various on-going talks about use of newer HTML5 features that aren't supported in IE8. For the most part, as @matmarex mentions, use of those doesn't have to break older browsers and isn't limited or specific to IE8, either.
With other IE versions, we sometimes had significant maintenance cost due to CSS support issues. Opera 12 for example has issues with SVGs in background images (in so far that it supports it when it shouldn't, so our normal PNG fallback requires Opera 12 specific logic to kick in).
For IE 8, I don't recall any particular issues that are blocked. In any event, at the moment IE6 and IE7 are also still supported from a basic Grade C perspective and while for WMF traffic for those is near zero due to use of HTTPS, that isn't related to MediaWiki core specifically.
So I'm declining this task because there doesn't appear to be anything specific to IE8 that would cause problems. Most likely if we find issues with the Grade C experience that affect IE8, it's quite likely to affect other (including, newer) browsers in that mode as well. If at some point we find IE8 specifically is causing a maintenance burden we can consider it, but even then we should probably think about dropping Grade C support for IE6 and IE7 first. Per https://www.mediawiki.org/wiki/Compatibility#Browser_support_matrix