⚓ T118303 Drop JavaScript support for IE8 (remove from "Grade A")
Page MenuHomePhabricator

Drop JavaScript support for IE8 (remove from "Grade A")
Closed, ResolvedPublic

Description

Released in 2009. Only browser we support that doesn't support ES5. Repeated source of problems that get missed. In September 2015 it was 0.548% of traffic (compare with IE7, at 0.983% which we dropped some time ago). For consideration. In November 2015 it was reported as 0.78% of traffic (IE7: 1.52%; IE6: 0.34%).

Event Timeline

We should announce this and note it in the release notes.

Yes. Let's remember that we still insist on providing an adequate user experience for non-JS browsers, so dropping support for IE8 does not mean users on IE8 would be left in the dark.

Krinkle renamed this task from Drop JavaScript support for IE8 to Drop Grade A support for IE8.Nov 10 2015, 6:55 PM
Jdforrester-WMF renamed this task from Drop Grade A support for IE8 to Drop JavaScript support for IE8 (remove from "Grade A").Nov 10 2015, 6:56 PM
Jdforrester-WMF removed a subscriber: Legoktm.
Jdforrester-WMF added a subscriber: Legoktm.

I'd like to clarify that, given current traffic of IE8, I think it would be a mistake to tolerate runtime failure in IE8.

Reader experience for IE8 users should at least remain "basic" as defined at https://www.mediawiki.org/wiki/Compatibility.

I agree we should drop support for Grade A experience in IE8. Or more precisely, require ES5. Which I've been advocating for a few months now as an objective to achieve by the end of this calendar year 2015.

This means that server-side interaction (e.g. HTTP level), and content and layout accessibility (HTML/CSS) remains supported.

Change 252383 had a related patch set uploaded (by Jforrester):
[DONOTMERGE] startup.js Move IE8 from Grade A to Grade C

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

Johan subscribed.

When would you expect this to happen?

When would you expect this to happen?

January.

Wouldn't this implicate at the same time, that we can't fully support HTML5 Elements without extra <div> wrappers for a long(/eternal) time(s)?
Because in IE 6-8 HTML5 elements can hold children and are affected by CSS only by help of JavaScript.

Or would it be a special treatment for a special friend out of Grade C browsers to include one JS in a conditional comment in head exclusively for IE with JS enabled?

// Append JS shiv for supporting HTML5 elements in IE<9 @media screen 
$min = $this->getRequest()->getFuzzyBool( 'debug' ) ? '' : '.min';
$out->addHeadItem( 'html5shiv',
	'<!--[if lt IE 9]><script src="'
		htmlspecialchars(
			$this->getConfig()->get( 'LocalStylePath' ) .
			"/{$this->stylename}/resources/vendor/html5shiv{$min}.js"
		) .
	'"></script><![endif]-->'
);

Wouldn't this implicate at the same time, that we can't fully support HTML5 Elements without extra <div> wrappers for a long(/eternal) time(s)?
Because in IE 6-8 HTML5 elements can hold children and are affected by CSS only by help of JavaScript.

Or would it be a special treatment for a special friend out of Grade C browsers to include one JS in a conditional comment in head exclusively for IE with JS enabled?

Given that we already have this problem with IE6 and IE7 users (for over a year now), I don't think this issue should block the problem. I created T122965 to discuss this.

Change 252383 merged by jenkins-bot:
startup.js: Move IE8 down from Grade A to Grade C

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