HTML 5 logo
Mobile, Web Development

Are You Ready for HTML5?

I recently attended a workshop on HTML5. It has been around for a while now, but I still learned a lot of new stuff. This post gives an overview of the new things I learned during the session and provides some benefits and drawbacks of adopting HTML5 in your web sites right now.

I had some experience with HTML5’s new features when I was creating a mobile application using HTML/Javascript, but this workshop really freshened up my HTML5 knowledge. The workshop was facilitated by Mathias Bynens, most of the topics I touch upon are inspired by his course material.


What exactly is HTML5? I won’t bore you with the technical details, but mostly when people drop the HTML5-bomb they are talking about more than just the HTML5 specification. Javascript API’s for geolocation and CSS3 don’t really belong to the “HTML5 specification”, but people keep mentioning them in the same breath. As with all de-facto standards, why fight the masses on this point?

Mathias presented the new HTML5 features in a neat way, in what he calls the three levels of HTML5. I recommend you take a look at his post first, as it succinctly summarizes all the new bells and whistles.

A short summary of the three levels:

  • Level 1 You can use these features for free: this stuff just works without any hassle, even in older browsers. This level encompasses cleaner syntax (plain and simple DOCTYPES and // <![CDATA[
    tags!), which is already supported by older browsers’ parsing algorithms. This level also includes redefined semantics of the existing purely-visual tags like the element.
  • Level 2 Nice to haves if the user’s browser supports it, but older browsers will still render your page without breaking anything (be it less fancy). This concept is called graceful degradation. Examples of features in this level are new form input types and the placeholder attribute.
  • Level 3 If you want to use these new features on your website and still want to support older browsers, you’ll need to perform some extra work (in the sense of feature detection and fallbacks, but we’ll get to that later). If you don’t tend to these things, your website will behave differently or will plainly break in older browsers. Examples in this category range from new structuring elements like
    to native browser support for displaying and . A lot of these features don’t consist of plain HTML, but require the use of their counterpart JavaScript API’s.

Living on the edge

A downside to living on the bleeding edge is that you have to deal with different browser implementations and different levels of support in each browser. This is ever so true when it comes to web technologies. A quick look at websites like caniuse and html5please serves as enough proof. For example, the websockets API still has no native implementation in the Android browser.

Why would you want to use these new features if all they bring is more work than before? A lot has already been written on this topic. Personally, I think the answer to this question is twofold:

First, the new features provide a better and more consistent user experience. For example, the element displays video in the user’s browser using the browser’s native controls. This means that stuff like the like volume control and the pause button of videos on your website will all feel familiar to the user out-of-the-box. No need for browser-specific styling!

Second, the Web is everywhere, and its influence will only increase in the future. Evolving towards the (next) industry standard will make your website future-proof. For example, making your website mobile-friendly will become less of a pain, since mobile devices are rapidly implementing HTML5.


So, you want to start adopting HTML5 in your website but you would still like all of your users, even the ones using older browsers, to have access to the full content. Fun fact: 10% (!) of your users are still using Internet Explorer 8, which means that these users would miss out on your cool images drawn on a or your chat widget implemented with websockets.

There are ways to provide a consistent experience to all of your users using fallbacks. Fallbacks can be divided into two groups, HTML-based fallbacks and fallbacks for HTML5 Javascript API’s.

HTML fallbacks

HTML elements themselves provide a fallback mechanism. An example any web developer is familiar with is the following age-old <a title=”” href=”; target=”_blank”>noframes fallback: 

  Your browser does not support frames

The new HTML5 elements allow for fallbacks as well. For example, all html code inside a tag will be rendered in case the browser does not support it.


The canvas will be neatly drawn in modern browsers and the img tag will not be rendered. When an older browser tries to render this html however, it will render the image instead.

Javascript fallbacks

You can also provide a fallback mechanism for any new JavaScript API’s you use. The main process of providing a custom fallback follows this pattern:

  1. Detect whether a HTML5 feature is available in the browser using JavaScript.
  2. If the feature is not available, include a custom implementation that tries to approximate the expected behavior as closely as possible.

Feature detection

You can manually detect whether a feature is available in the browser by writing your own logic. For example, when you want to detect whether the browser supports geolocation, you can use the following snippet:

function geolocationIsSupported() {
    return 'geolocation' in navigator;

Instead of writing these (often quite inventive, as not to say please-don’t-try-this-at-home) snippets,  you can resort to Modernizr, a fully-customizable Javascript library that does the feature detection for you.

Fallback implementations

So now you can identify when a user’s browser does not support a feature, but you still want to provide him the best experience possible. Moreover, you don’t want to clutter your entire codebase with conditional statements in case a browser has no support for the feature. This is where fallbacks come into play. There are a lot of different names for these fallbacks, but I’ll just refer to them as polyfills in the remainder of this discussion. These fallbacks provide the same API as the browser would have, as if it natively supported the feature. This technique flattens the API landscape so the rest of your Javascript does not have accomodate for the fact that this feature is missing. I love the origins of this term: the name stems from Polyfilla, a product used to fill cracks in physical walls.

There are some nice catalogs of polyfills, so you don’t have to roll your own.

Does it make sense to provide fallbacks for all of the new features your web site uses? The answer depends on your website’s requirements. If your website needs an exact real-time position of your user, using a geolocation polyfill that uses (less precise) IP-based geolocation on devices that do not have a GPS sensor will not cut it for you. Polyfills try to mimick the existing API as close as is reasonable, but cannot always provide the same level of quality. A fallback often results in a somewhat degraded experience, so it’s a trade-off between legacy browser support one way and higher levels of quality, user experience and an increased development effort on the other side.

Fun fact about

Something that really struck me during the workshop was the current browser support for the element. Each modern browser supports it, but each browser supports a different file format for your video files. This effectively means that in order to get your video playing in all browsers, you need to provide multiple video files in different encodings. This fragmentation is mainly due to patent issues. Over time, browsers have converged on somewhat “standard” support, so you now only have to include two different encodings:


This is also another example of the HTML5 native fallback strategy: you provide multiple fallback options and the browser will select the most appropriate one.


HTML5 provides a lot of features that can improve your users’ browsing experience. So, should you start incorporating HTML5 in all your web sites?

I think the answer is a bit nuanced:

For the Level 1 features it’s a no-brainer: implementing them will result in a neater HTML structure (like cleaner DOCTYPE and script tags) and will give your site’s content more semantic value (header, nav, footer, article,…). Search bots and screen readers can better interpret your site and as a result decide which content on your site is important. Plus, the level 1 features will not break anything when rendered in older browsers, so there really is no reason to not start using them right now.

Level 2, the nice-to-haves of HTML5, improve the user experience and degrade gracefully, but you should be aware that users with older browsers will have a different (but still functional) browsing experience.

Level 3 is where the real choice has to be made. If you only have to support the latest browsers, you can go all out on the new features. If you work in a standard corporate environment, chances are you will still have to support older browsers. In this case, if your web site doesn’t need geolocation, client-side storage or fancy vector animations you can steer clear of these features and live a worry-free life. If you do have to incorporate these features and want to support older browsers, prepare for a little extra work. You will need to incorporate feature detection and provide fallbacks for the functionality you wish to use. Thankfully, there are libraries and existing fallbacks that take care of most of the heavy lifting for you.

HTML5 was built with backwards compatibility in mind. This means that you can gradually start introducing HTML5 in your landscape and that HTML5 and pre-HTML5 websites can peacefully coexist.

If all this has gotten you interested in adopting HTML5 I suggest you get in touch with Mathias, as his excellent HTML5 workshop laid the foundations for this post.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s