HTML5 is here! Or has been for a long time. Or never will be. It all depends on your point of view.
Since a picture is worth a thousand words, take a look at the HTML5 illustration found on Wikipedia.
As you can see, HTML5 is no single entity. It’s a moniker for a group of specifications at various stages of the standardization process. Some have been in use for years already, others are just now arriving in current browsers, and some will never be implemented.
Been there, done that
As an example for the “vintage” areas of HTML5, take the Canvas API. At its core, it’s a set of JavaScript commands for drawing vector and pixel graphics. And at PTV, we’ve been using it since 2006 for client-side graphics in the AjaxMaps component.
The Canvas API was originally introduced by Apple in 2004 and quickly adopted by other browser vendors. Only Microsoft didn’t include it until Internet Explorer 9. However, there’s a clever JavaScript library released by Google that implements the Canvas API using VML (a proprietary Vector Markup Language created by Microsoft) in older IE versions. So at least this part of HTML5 has been in use for years. What about others?
Unfortunately, support for various HTML5 features is all over the map – from widely adopted to non-existent. For example, take a look at the compatibility table on caniuse.com for Web Sockets.
The power of standardization
Perhaps the most important point of HTML5 is that browser vendors are talking to each other and that standards are published as a result. To understand why this is a big deal, just look at the past few years. After HTML4 and XHTML, the World Wide Web Consortium (W3C) failed to address the needs of both web developers and end users. Specifications like XHTML 2.0 did little to facilitate the creation of exciting new web applications but mainly added bureaucracy. The result was a “Wild West” situation where browser vendors added new stuff as they saw fit, and others followed – or not.
It soon became clear that this model wasn’t sustainable. At Microsoft, browser development slowed to a crawl. Web apps couldn’t use new features if they were hoping to reach a decent percentage of users. And the W3C could not be convinced that it was headed in the wrong direction. This led to the formation of the WHATWG (Web Hypertext Application Technology Working Group), initially formed by Opera and Mozilla and later joined by Apple. HTML5 orginated at the WHATWG starting in 2004, and it took until 2007 for the W3C to finally accept it as the basis for future web standards.
Of course, there’s still no browser with full support for HTML5. And since the standardization process is far from finished, there won’t be for the forseeable future, if ever. But we can already enjoy the first fruits of this labor: The Canvas API mentioned above can be used on all modern browsers, both on the desktop and on mobile devices. The same is true for Web Storage, and other parts of HTML5 will follow. So while there’s still a long way to go, the journey has at least started, and everybody has agreed to the general direction.
To boldly go …
As HTML5 matures, there will be a slew of new possibilities for web apps. One direction that we’re exploring at PTV is plugin-free, vector-based mapping in the browser.
These maps work in all modern browsers and require only a fraction of the bandwidth compared to bitmap tiles. The colors, line thickness, and other properties can be changed on the fly. And since the data is vector based, the same map tiles that look good in a desktop browser are razor-sharp on the new Retina Display iPads.
This couldn’t have been done even two years ago. And HTML5 features like geolocation, offline support, web workers, and many others will open up even more possibilities.
So should you jump on the HTML5 bandwagon? Absolutely! Will it be a smooth ride? Surely not. You’ll still need feature checks, fallback solutions, and compatibility hacks. And your web apps will still break in certain browsers. But you can also do things that weren’t possible before, and support for HTML5 will only get better.
Thanks to Andras Junghans (of Junghans und Schneider) for this highly interesting article!