Should we be using HTML5 now?

To say that HTML5 is creating a bit of a buzz in the web community at the moment would be a bit of an understatement. It has become the poster-boy and catch-all term for a number of exciting developments in web technologies. Here I am looking at it in undiluted form: as an iteration of the HTML language for building websites.

I had my first brushes with HTML5 at web conferences last summer. It piqued my interest. It prompted me to buy Introducing HTML5, which, as the title suggests is a fantastic introduction to the technology. The book inspired me to get my hands dirty and use it to structure this blog.

Since then I’ve been thinking a lot about the practicalities of using HTML5 more widely. For real projects. And really big projects.

Using HTML5 now

The experts have been telling us to dive in for a while.

If my heart rules, I am inclined to recommend going with the flow…

  • It allows you to produce cleaner more semantically meaningful markup which benefits real people, search engines and assistive technologies;
  • There are lots of bells and whistles to help you to develop a more engaging user experience;
  • It gets you experience early doors with what will become the de facto standard, which is great from a personal development point of view.

…there is a but coming…

But what about the websites for large organisations whose websites attract audiences which are varied and number many? Is it appropriate to dive in? Do we risk alienating a significant number of our users?

I work for one such organisation. Most people view its website using Internet Explorer versions 6-8. And while there is a JavaScript workaround to enable the HTML5 elements to be recognised by these browsers, the needs of those with JavaScript disabled have to be considered. Yahoo! recently looked into how many people were using their homepage in this way. They discovered that the proportion of users was very low (a few percent), however given the size of their user-base, this still represented a huge volume of traffic.

Yes and no

What the Yahoo! example highlights is that this decision should be guided by the needs of your users. If you have concluded that HTML5 is fit for your purpose now, there is no need to read on: use the time to draw up your plan of action.

For most it is probably not so clear cut. It is a risk to dive in: the effect of alienating even a small proportion of your audience is magnified if traffic to the site is high. Not doing so also has risks: stagnation and potentially falling behind braver competitors. Both options bring benefits and have risks.

Still, I’d like to take ‘no’ as an option off the table.

Is there another alternative?

This is the question I have been asking myself. And the conclusion I came to was a resounding yes!

To use the class property to add semantic meaning to existing generic HTML elements, like <div> and <span>. The values of the class property would be goverened by the new, semantically rich HTML5 elements: header, nav, section, aside, footer et al.

Then the other day, I discovered that Jon Tan┬áhad written a wonderfully detailed article on this approach back in March 2008…

Having sat on this idea for about 6 months while working out the detail, it turns out that I am already three years late to this party. To quote Homer Simpson: D’oh!

There is more – expanding on an idea

Where Jon falls short in his article is in advocating the use of the HTML5 doctype: <!doctype html>. By declaring this doctype you are helping to future-proof your web pages, even if you aren’t yet taking advantage of the sparkling new semantic elements on offer.

What it allows for is the selective implementation of other parts of the HTML5 specification now – where incorporating a feature would provide a real benefit to user-experience, whilst avoiding alienating vast tracts of your audience. You are creating a platform ready for enhancement.

One area ripe for using this approach is in the delivery of video – currently Flash-assisted is the method du jour. This is problematic for users of Apple’s iPad and iPhone as neither device runs Flash. Both support HTML5 and the <video> element. It is possible to combine the two – using the HTML5 <video> element as the primary way to deliver video, with the Flash-assisted technique as a fallback. If you have a large user-base on portable Apple technology the benefit is clear – it broadens the reach of your content.

Removing class boundaries

In the future there will come a point at which you want to update this hybridised markup and go full HTML5. I have an idea about that too…

If the markup is structured in a consistent manner (i.e. class is always the first property declared in the HTML element) then you should be able to find and replace your way through the HTML and associated CSS rules.

I’m still yet to work out how you would handle closing tags…and then there is JavaScript. But it’s a start. Take the idea and run with it, and let me know how you build on it!