HTML5 Video and iPad - A Solution?

HTML5 Video and iPad - A Solution?

I'm not a 'developer' or an 'engineer', but I just wanted a responsive video on a web page that would play across browsers and OS. How hard could that be? Now, I've done that with the old iFrame-contained video players, but with HTML5 it promised to be so much easier. How wrong could I be!

Some Background

I don't usually crow, but I found little on the interweb to help me overcome some simple problems with using HTML5 video across browsers and OS. This may help you overcome issues and problems with iPad HTML5 video policies. The main policy is that iPad/IOS will not download the video headers (or video poster images) before one clicks Play. This can leave an empty space with an IOS play button, but no visually semantic indication of there being a video in place; a poor experience if the video button falls below 'the fold'.

A client wanted to display a single video on a page. Nothing else. Just that. No header or other semantic markup; just the video (and yes, I know that's so wrong but they pay me to keep quiet). They also didn't want to use an off-the-shelf video player that required an iFrame as iFrames can be naughty toward security.

This set my mind wondering and I embarked on what was to become a frustrating journey implementing what I had believed to be a modern video standard: HTML5 video.

Problems with HTML5 Video

Several problems slowed my progress building the video presentation page:

  • Typically, browser vendors appear to have disagreed on what video file type/s should be 'standard'. HTML5 is still in DRAFT.
  • The video tag allows for a 'poster' image, but IOS (Chrome for iPad) declined to display it - or anything except its own Play button.
  • The video tag can be made responsive by giving it a width of 100% and removing its height attribute in the HTML, or by using CSS. But again, IOS (Chrome for iPad) declined to display the height correctly, forcing the video to be as tall as its container regardless of viewport/container width.


Thanks largely to a variety of poorly connected answers on Stack Overflow and an already crusty book, Matt West (2013), HTML5 Foundations, Treehouse for Wiley & Sons, Chichester, I cobbled together an iterative number of techniques and strategies to overcome IOS and all other browsers after IE9. The irony of IOS (iPad) being difficult in 2016 isn't lost on me: it's rapidly becoming as much a thorn in the side as ever was IE6!

So, what did I do?

Part One: The HTML5

Firstly, I wrote my standard HTML5 drawn from W3C Schools. This allows for 'fallback' video formats. With previous experience of video players that need iFrame, I placed the video snippet inside an article. The article was just an arbitrary container: it could be a layer (div) or almost any other out-of-the-box or styled block level element just as easily. All this sat within a section, which although not semantically correct given the lack of content, was lying around needing using.

<section class="mainContent">
    <article class="videoArticle">
    <video width="100%" playsinline controls poster="img/video_poster.jpg">
 <source src="video/Tutorial01_create.mp4" type="video/mp4" />
    <source src="video/Tutorial01_create.ogg" type="video/ogg" />
    <p>Your browser will not play this video format. 
    Please <a href="video/Tutorial01_create.mp4">download the video to your desktop</a>, 
    or update your browser to enjoy this content.</p>

So that bit is easy, but recall you can declare other video file types too. The <video> element also enables a fallback text for when the player isn't supported. I added a link to the video file in the notice so our user can still access the tutorials even if their browsers are awkward. (2016, and we still cannot rely on a browser to be 'standard'? I despair!)

Oh, and as this page is cross-browser/device fluid-responsive, I added the all important viewport scale meta data at the head of the document:

  <meta name="viewport" content="width=device-width, initial-scale=1.0" />

Part Two: You Cannot Click the Poster Image and Play!

Oh, dear. What a pickle. You'd just imagine that as you can add a poster image that you could click it to play the HTML5 video? It's a basic precept of usability to have a large hit area, and here we are reduced to a sub-30px Play icon in the control bar. Sheesh! It's 2016 guys!?

Anyway, I found a short JQuery snippet to interrogate the video and to determine when the poster or the video controls are being clicked. This is important as early examples I found removed the function of the controls! (Again, it's 2016 and these basics are still being overlooked.)

The snippet:

<script type="text/javascript">
$( document ).ready(function() {
  $("video").click(function (e) {
    if(e.offsetY < ($(this).height() - 36)) // Check to see if controls where clicked

Note:If you follow this, remember to do the 'document ready' function bit. It's worth noting the use of the 'click' function can stump touch-devices. I'll work in a touch solution later. For now it works with the generic touch browser functionality and whatever time delay their 'press' or 'tap' event is set to.

Part Three: IOS Shows Nothing But Its Own Play Button

Seriously, after all this following of HTML5 'standards', which to be fair I know are still in DARFT, but it is 2016, I still had issues with IOS. The poster and video 'presence' - its UI - just fails to show. Nothing is downloaded and so <video> has no style.

I worked out the solution for myself by simply adding the poster image to the video's parent container. In this case, the article. I also gave it to a CSS style for 'video(poster)'. I don't really know if that has helped across browsers, but it seemed worth a shot?

Part Four: Remove the IOS Play Button

The IOS Play button was not in itself an issue except that my 'poster' image was of a Play button so it looked 'wrong' and had to go. After a little searching through CSS Blogs I found consensus with the following CSS snippet:

*::-webkit-media-controls-start-playback-button {/*remove IOS button*/
  display: none!important;
  -webkit-appearance: none;

This gets into Apple's 'shadow DOM' and throws out that button. Cool.

So now my CSS looked like this:

.videoArticle {
 margin:2em auto;
 background:grey url(img/video_poster.jpg) no-repeat 0 0;/* to show in IOS */
video, object {
video(poster) {
 background:grey url(img/video_poster.jpg) no-repeat 0 0;
/*IF you want to remove IOS Play overlay, use this:
*::-webkit-media-controls-start-playback-button {/*remove IOS button*/
  display: none!important;
  -webkit-appearance: none;

On reflection, and following the discovery of a similar overlay in Firefox, I left the browsers to their own defaults. I get the reason they are there, and the only issue was the poster image, which I updated to avoid the visual conflict. We can't go around fighting every browser default can we..?

And I was feeling pretty proud of myself, too. (And so this post...)


It's 2016 and still we need to consult across multiple channels to get simple presentation achieved in our browser based apps and products. What? Sigh. However, with a little tenacity, a smidgeon of knowledge, and a number of great problem solvers blogging and whining across the interweb, I was able to overcome this little speed bump without too much pain.

I hope it helps someone to see the solution all in one bag? Anyway, I'm off to go smarten this all up ready to head off the engineers from their 10,000 lines of JS to overcome the same problems... :)


Popular posts from this blog

Click or Tap? Misunderstanding of Affordance

Why use a Quick Reference code on your crafts and products?

"Click Here" for Useful Link Writing