I recently had the opportunity to implement an HTML5 video for a client.  It was the first time I’d really worked with HTML5 video, and I ran into a few issues and quirks I thought I’d share for other developers who run into these issues.

At first I started implementing my video in Flash with a fallback to HTML5 – not for any special reason, but only because a previous developer had implemented another of the client’s videos that way and I followed the pattern already set.  I soon discovered that although this works fine for a video that just plays in a fairly static page, it wasn’t ideal for the kind of video I was implementing, which required some custom controls and interactions with other elements on the page.  I first thought that the best way to handle this would be with a try / catch, but since my flash took a little bit of time to load, I would often get an exception when calling a flash function, even though the flash was ultimately playable.  The real crux of the problem was that in an HTML5 to Flash fallback implementation, the flash code doesn’t even exist as far as the browser is concerned unless HTML5 is not supported – in which case the <video> tags don’t exist.  The user can only ever interact with the HTML5 video or with the Flash – never with both.  If you implement it the opposite way, BOTH Flash and HTML5 video exist on the page, potentially leading to a situation where the user is interacting with both videos.  Once I found myself writing code to catch and prevent these weird interactions, I decided this was the wrong way to go.   The HTML5 to Flash fallback is the way this code is meant to be implemented, and leads to the cleanest implementation.