theres videojs ie8, not sure if that will work for us, but theres no ie 7 or 6 videojs player.

JavaScript seems to be disabled mw core end on ie 8 or lower.

@Paladox: See the task description:

should probably show a poster image and link to the File: page for download in the fallback content of the <audio> or <video> element.

Hence intentionally no plans for some videojs stuff here or anything else.

JavaScript seems to be disabled mw core end on ie 8 or lower.

It is.

Change 317313 had a related patch set uploaded (by TheDJ):
[WIP] Provide <video> fallback content

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

Hmm, i have a lot of open questions on this. UI wise it's pretty shitty no matter what you do, File page linking vs download media remains a problem (which goes where?), and it's a lot of extra bytes...

In T148586#2735905, @TheDJ wrote:

Hmm, i have a lot of open questions on this. UI wise it's pretty shitty no matter what you do, File page linking vs download media remains a problem (which goes where?), and it's a lot of extra bytes...

If it's worth trying a good UX I'd recommend having the inline view's fallback poster <a><img></a> link directly to the derivatives download list on the file page, or else making a clean non-JS download table in a special page and linking to that instead of the file page.

In this case our fallback content cost would be... couple of URLs, tags+width/height, and an alt text saying something like "Download". This is probably peanuts compared to the list of <source> and <track> elements we've already got. :)

@Krinkle I'm not sure we need T122965 for this; the fallback content should "just work" and the contained image would behave the same as the <video> in terms of its sizing and inline-block nature.

I've put a pen of the current patch in a pen, to make it easier to play with, since it's hard to check what fallback content does on modern browsers. The example replaces <video> and <audio> with spans (unknown elements are rendered as inline blocks)

Alternative without play button styling (current mobile version)

For the IE issue, i'll need to check at home, as downloading VMs on this network is a bit hard, and I couldn't get any of the browser screenshot site that had actually working IE instances today)

@TheDJ there's https://www.browserstack.com which allows testing sites in ie.

• Download media
• one link
• no image for audio
• single a around both elements
• IE8 does not need any HTML5 element fallback it seems.
• IE9 has support for <video>, but we don't add our JS enhancements there. So how to fallback. noRLQ fallback, like for graph...

Ok we tested this at wmhack. Quick note we need special handling for IE9, which supports <video> but none of our codecs (or ogv.js) and also gets grade C non-JS mode.

Should work to use something like this: <video ... onerror="if (body.className.match(/no-js/) this.outerHTML = this.innerHTML">...</video> Might want to double-confirm that the error is a 'codec not supported' error, but that's an easy check.

Poop, error isn't thrown until play when using preload=none. We'll need to manually check the sources against .canPlayType() via a small JS function. We'll also possibly want this for other old browsers that get degraded in future that don't have native ogg/webm but do have HTML5 video.

Change 317313 abandoned by TheDJ:
[WIP] Provide <video> fallback content

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

Update for 2019:

• Grade A (js-enabled) now only needs to cover IE11+ and Edge.
• Grade C (no-js) covers IE 6 - IE 10.
• MediaWiki ships html5shiv on all views.

Does this make the fallback simpler? In particular, I'm hoping T148586#3282956 from @TheDJ would now be easy/easier..

DOM output for non-JS browsers is almost identical between the two players:

KalturaPlayer:

<video id="mwe_player_0" poster="…" controls="" preload="none" style="width:800px;height:450px" class="kskin" data-durationhint="91.146" data-startoffset="0" data-mwtitle="…" data-mwprovider="local" data-vscid="…">
	<source src="….webm.120p.vp9.webm" …>
	<source src="….webm.160p.webm" …>
	<source src="….webm.180p.vp9.webm" …>
	<source src="….webm.240p.vp9.webm" …>
	<source src="….webm.240p.webm" …>
	<source src="….webm.360p.vp9.webm" …>
	<source src="….webm.360p.webm" …>
	<source src="….webm.480p.vp9.webm" …>
	<source src="….webm.480p.webm" …>
	<source src="….webm.720p.vp9.webm" …>
	<source src="….webm.720p.webm" …>
	<source src="….webm.1080p.vp9.webm" …>
	<source src="….webm.1080p.webm" …>
	<source src="….webm" …>
</video>

VideoJS:

<video id="mwe_player_0" poster="…" controls="" preload="none" width="800" height="450" data-durationhint="91.146" data-startoffset="0" data-mwtitle="…" data-mwprovider="local" data-vscid="…">
	<source src="….webm.120p.vp9.webm" …>
	<source src="….webm.160p.webm" …>
	<source src="….webm.180p.vp9.webm" …>
	<source src="….webm.240p.vp9.webm" …>
	<source src="….webm.240p.webm" …>
	<source src="….webm.360p.vp9.webm" …>
	<source src="….webm.360p.webm" …>
	<source src="….webm.480p.vp9.webm" …>
	<source src="….webm.480p.webm" …>
	<source src="….webm.720p.vp9.webm" …>
	<source src="….webm.720p.webm" …>
	<source src="….webm.1080p.vp9.webm" …>
	<source src="….webm.1080p.webm" …>
	<source src=".webm" …>
</video>

Both will fall back to native controls, which work fine for me in current Chrome/Firefox/Safari from local testing. For IE6–8 this means "nothing", AIUI, including for the current experience. I think that's reasonable behaviour, and I don't know if we need to block release on trying to serve these users better?

Ehhh, it's not hard to add a fallback image link that points to the file page. But I wouldn't necessarily block on it if it's not done soon.

(main difference from previous behavior is that in practice most videos got the image with popup link where now they get a video directly)

I think It can be closed because of T248061.