When your client asks for a web site design to be in HTML5, what does that mean?
Generally speaking—when a client requests HTML5, it means that they want the project to run across all devices (no Flash) and they don’t want to spend a lot of money.
And while many developers talk like HTML5 is the next best thing, possibly destined to save the world, the reality isn’t quite so simple. Here is a quick introduction to what HTML5 can and can’t do for you.
To start, you need to know a little history and a few details.
Web site design with HTML, a history
1989 – HTML is born
1995 – HTML 2.0 is released, and the browser wars begin
1996 – W3C takes over the specifications
1997 – CSS 1.0, HTML 4.0 are released
1999 – XHTML 1.0 is released
2002 – XHTML 2.0 is released
2004 – W3C votes against continuing work on HTML
2007 – Work begins on HTML5
2008 – The first draft of HTML5 published
2014 – Target date for making HTML5 a W3C Recommendation
Despite not being a W3C recommendation yet, browsers have adopted it to various degrees.
And while HTML5 is opening the frontiers of what can be done—it also summons up a sense of deja vu from the days of 1995 where every browser had its own quirks.
The price of this is more time spent chasing cross-browser bugs, and surfing the ‘net for hacks to make pages work on different browsers, and experimenting in the search for new solutions. The good news is that for straightforward, simple web pages, it isn’t much of a problem.
But the bad news is that for some of the more advanced features you have to be careful. See wikipedia for a comparison chart of supported/unsupported features to see what I mean.
Regardless, HTML5 is here today, and growing.
So what is so great about HTML5, and how does it affect me now?
First of all—HTML5 is planned to be the web standard in 2014. Whether you should rush out and convert all of your web pages to it right now depends on whether you really need the features that make HTML5 stand out. To that end—I have listed out some of those key features:
- Support for video elements (this is part of the “No Flash” feature)
- Canvas for Images – lets you apply filters and manipulate images and use vector graphics
- Geolocation – reports the user’s location to the web page
- Offline Application Cache – basically allows for smarter web page caching
- Local storage – similar to cookies, but allows for more data to be stored and nothing is sent back to the server
- Web workers – run JavaScript in isolated threads
- Better form support
- Semantic markup
Note that a lot of these features are driven by two main desires.
First: to get away from proprietary plugins (meaning Flash and Java). And second: to provide a robust technical framework for making web pages act more like software applications.
From a client’s view, these are all technical issues that they may not understand, or—for the most part—even care about. And it should also be noted that all but the last of those are only important if your web site needs the feature.
So you have to ask some questions about your project:
- Does your site have videos?
- Do your images have any special requirements?
- Do you really care where your web visitor is?
- Is your site a web site or a web application (such as a web-based word processor)?
In short, for a lot of web sites, these are not really important features. And you should ask what the downsides are for the features. It pretty much will come down to the difference in development costs, the life-cycle costs, and the requirements. This is true for both the client and the developer.
The last feature (semantic web) has been the buzzword for years (Tim Berners-Lee, the inventor of the web, wrote about it in 1998). But for most clients, the actual benefit is unclear. It is supposed to make it easier for search engines to better understand the content of a web site. Does that mean if you recode your site in HTML5 you will suddenly be at the top of the search engine ratings? Not likely.
Eventually, HTML5 will be widespread and standard with most browsers supporting most features.
Kind of like the situation with XHTML today. If you have a specific requirement/need that XHTML does not meet and that HTML5 does, then look into solving the problem with HTML5.
If you are a developer you should begin to learn HTML5, but use it only when it makes sense: when its features are required and/or the cost to the client is less. Do not use it just because it is the new shiny thing, especially not until you understand the tradeoffs with cross-browser issues and costs.
There are many evangelical web articles on HTML5, so I am not going to list those. Instead—here are a few explaining the other side of the coin.