Provide a way to support HTML5 elements in browsers that don't support it and don't have JS shipped, like IE8 and below
Closed, ResolvedPublic

Description

From T118303#1855079:

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]-->'
);

Related Objects

Jdforrester-WMF updated the task description. (Show Details)
Jdforrester-WMF raised the priority of this task from to Needs Triage.
Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald TranscriptJan 6 2016, 4:50 PM
Krenair added a subscriber: Krenair.Jan 6 2016, 5:20 PM

CCing Scott as he said he was looking at this already in the context of support for <figure> elements in the DOM.

TheDJ added a subscriber: TheDJ.Jan 6 2016, 6:18 PM

I'd say, just use an IE conditional html5shim, but it's not a blocker. The elements we use are limited, the most high use element is probably <video> and that already takes care of this itself if I remember correctly...

cscott added a comment.EditedJan 6 2016, 7:32 PM

The required output is really very simple. In the <head> (or at the beginning of <body> -- the important thing is that it precede any usage of HTML5 tags not recognized by IE, such as <figure>,<section>, etc:

<script>document.createElement('figure');document.createElement('section')<!--etc--></script>

For generality, we should probably create an MW API method that will add a new tag name to this set, so that extensions can register (say) <gallery> in the future if they wish. And we might find some way to minimize that code if the tag name list grows long. "figure,section,foo,bar".split(",").map(document.createElement) perhaps. But we can KISS to start.

(And at the moment, just including that fragment on all browsers is faster and smaller than trying to use IE conditional comments to load a shim file.)

@cscott Given the long history of html5shiv, it's widely tested, successful usage and support of edge cases I would rather urge for using it or orienting strongly on it. It also comes with support for custom elements.
Might there not be negative caching implications by inlining, especially on IE8? Also it needs to come after all stylesheets, to properly apply the styles in IE.

Volker_E renamed this task from Provide a way to support HTML5 in browsers that don't support it and don't have JS shipped, like IE8 and below to Provide a way to support HTML5 elements in browsers that don't support it and don't have JS shipped, like IE8 and below.Jan 6 2016, 10:31 PM
Volker_E set Security to None.
Volker_E added a subscriber: GWicke.

There is a patch in gerrit that is disabling ie8 for javascript. It was announced a month or two ago that ie8 js supported will be disabled in mw core in January.

TheDJ added a comment.Jan 6 2016, 11:04 PM

@Paladox we are aware, but that means disabling support for anything ResourceLoader based and all ''features' provided by JS. It does not mean we cannot still make an IE8 specific 'hack' for this specifically. That is not without precedent.

@Paladox we are aware, but that means disabling support for anything ResourceLoader based and all ''features' provided by JS. It does not mean we cannot still make an IE8 specific 'hack' for this specifically. That is not without precedent.

Ok. I was referring to the suggestion to use a html5shiv library.

Jay8g added a subscriber: Jay8g.Jan 7 2016, 6:46 AM
Arlolra claimed this task.Jun 15 2017, 10:00 PM
Arlolra triaged this task as Normal priority.

Change 369991 had a related patch set uploaded (by Arlolra; owner: Arlolra):
[mediawiki/core@master] resources: Support HTML5 elements in older browsers

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

Change 369992 had a related patch set uploaded (by Arlolra; owner: Arlolra):
[mediawiki/services/parsoid@master] T122965: Support HTML5 elements in older browsers

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

Change 369991 merged by jenkins-bot:
[mediawiki/core@master] OutputPage: Support HTML5 elements in older browsers using html5shiv

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

Krinkle moved this task from Backlog to Done on the MediaWiki-Interface board.Aug 9 2017, 9:19 PM
TheDJ awarded a token.Aug 9 2017, 9:39 PM
Arlolra closed this task as Resolved.Aug 9 2017, 10:34 PM

@Arlorla Is Change 369992 not necessary to fully resolve?

@Arlorla Is Change 369992 not necessary to fully resolve?

Not really; I'm not sure any clients currently make use of Parsoid's <head> information. VE certainly doesn't. Also, that patch makes some assumptions about the result of OutputPage::transformResourcePath() that aren't very satisfying. I'm considering abandoning it.

Change 369992 merged by jenkins-bot:
[mediawiki/services/parsoid@master] T122965: Support HTML5 elements in older browsers

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