Remove Addressbar from iPhone Web App

If you are creating a web app for the iPhone there is an easy to to hide the address bar when opening the page from a link on the users home screen. You simply need to add the following meta tag to your
head. This will also work with the iPad.

<meta name="apple-mobile-web-app-capable" content="yes" />

iPad HTML Video Autoplay

The Problem

The iPad and also the iPhone have a bit of special behavior when it comes to using the HTML5 video tag. They both have the autoplay functionality shut off. This behavior is also extended to any event which the user has not started the event chain. (AKA you can’t do the following)

<body onLoad="document.myMovie.play()">

What it Means

So what this really means you can not have a playlist of videos where one video is loaded as soon as the first ends. Also having timed events from one video kick off sub videos will not work unless the user clicks on the new video.

Is this a Bug?

No this is as intended by Apple look for the Device-Specific Considerations here. What the idea is that any device that could be charged from a data plan shouldn’t allow auto play. While this idea makes sense the execution is poor. I am currently using a wifi only iPad so there is no reason for this restriction it would be best in my mind to detect if they are using wifi or 3g and react accordingly.

What to Do

Design around this I restructured an interaction from popping up this sub video over the main video to instead make a thumbnail active so it could be click to show this sub video this works in my case as the sub video can be viewed any time after the timed event.

Another option is to show the new video element that will display a play symbol you should be able to set a poster image with some text to guide the users.

HTML5 Video and the seeked event

I have been working with the HTML5 video element a bit on both iPad and the Chrome browser. I’ve started to find some odd behavior around the seeked event. First a touch of background about the seeked event. According to the spec the seeked event should fire when the seeking IDL attribute changes to false. This seems to make perfect sense but when actually using the event it seems inconsistent at best.

I have seen three distinct actions that don’t make sense to me.

Extra Fires

  • While dragging the scrub bar the seeked event will fire many times in the Google Chrome 5.0.342.9 beta on windows.
  • When setting the position by changing the currentTime attribute it will fire the seeked event three times in a row on both the iPad and Chrome.

No Fires

  • Scrubbing on the iPad never fires the seeked event.

So from what I can tell its not the best idea to use the seeked event at this point but the timeupdate event does fire consistently through my testing. So what you can do if you like is keep track of a last value for the timeupdate and then you can detect if it jumps too far (up to you and your use) then fire the logic you wanted to fire on seeked. I am kicking off events at times and I didn’t want to miss events so simply changing my logic to fire as long as the time is past the event point worked fine for my uses but that may not always work. Keeping track of the last time from the timeupdate shouldn’t be a very hard addition if you need special seek logic.

HTML5 Video Poster and the iPad

While working on a small HTML5 based project for the iPad I found some interesting things with how it handles the poster attribute and defining the video source. The following HTML works fine on Mobile Safari (iPad) and my desktop Chrome.

      <video id="vidtest" src="big_buck_bunny.mp4"  poster='poster.jpg' controls="controls">
      </video>

But moving to the following code works fine in Chrome but on the iPad (Mobile Safari) it will only show the poster and no way to start the video unless you do the pinch zoom to make the video full screen then the controls will show up.

       <video id="vidtest"  poster='poster.jpg' controls="controls" >
          <source src="big_buck_bunny.mp4" type="video/mp4" />
       </video>

Simply using the first style is ok if you are only doing one type of video but if you wanted to include other options this issue limits that ability. But for now if you are targeting iPad just use the first option.

DISQUS Comments

One feature I have really liked on my blogs recently is the ability to just use Twitter to comment so I went ahead and added the DISQUS Comment system the plugin is straight forward and easy to use with WordPress. Moving forward with new site projects I will be strongly considering using DISQUS instead of an internal comment system, I would suggest checking it out as well as InenseDebate .