HTML5: Towards a More Semantic Web

Christopher Lewicki
HTML5 is all the rage these days. If you stumble upon a group of nerds you’ll hear phrases like “offline storage”, “microdata” and “improved error handling”. But what does HTML5 mean to the average webmaster —the webmaster who just wants to display their content in the best way possible and not worry too much about the technical mumbo-jumbo which makes nerds’ trousers tight? In a nutshell, HTML5 provides a vastly expanded array of tags which allows for webmasters to describe what their content is and how it’s related right in the content itself.

Before embarking on the usage of HTML5, however, a brief aside regarding CSS 3 and JavaScript is required. Many of the “wow factor” HTML5 demonstrations floating around the web are primarily implemented in CSS 3 and the newest version of JavaScript. While these demos are impressive, they’re irrelevant to the semantic power of HTML5. A valid, useful and powerful website can be completely built in pure HTML5 without writing a single line of JavaScript or CSS.

In order to understand a little more what HTML5 will mean for you, it’s important to understand where it has come from and what, exactly it is. At the moment HTML5 is simply a proposal. HTML5 is a proposal which every major browser (including Internet Explorer 8+) supports to a lesser or greater extent, but, it is still just a proposal. The proposal status of HTML5 has lead some in web circles to proclaim that HTML5 isn’t quite ready to use yet. Fortunately, HTML5 is defined in such a way that content will still display properly in browsers which don’t yet implement all of the HTML5 specific features, providing a clean, simple upgrade path for webmaster.

HTML5 has something of a troubled history. In the mid-2000s it became obvious that the current version of HTML (4.x) simply did not provide the richness of features required for the next generation of website. To address this the World Wide Web Consortium (W3C) (the organization in charge of creating web standards) started creating a new standard based on very strictly defined eXtensible Markup Language (XML) called XHTML. If you happen to be a fetishist for code purity and have a PhD in the theory of programming languages, then XHTML is for you. For everyone else, XHTML was a disaster. It added a tremendous amount of complexity to creating even a simple web page, yet failed to provide useful features for most everyday web tasks.

In response to the debacle that was XHTML, a group comprised largely of web designers and people at Mozilla (creators of Firefox) began imagining their own standard. Instead of strict adherence to abstract programming concepts it would be based around the relatively simple HTML4 syntax and focus on adding useful elements to make it easy for designer to create sites which clearly identified what each portion of the site meant, not just how it looked. That project is what we now call HTML5.

To the academic programmer, steeped in the hierarchy of working groups and interminable committee processes an independent proposal, such as HTML5 is tantamount to hearsay, and HTML5 meet with lots of resistance. One form of this is the oft repeated fib that HTML5 will not be ready until 2022. Not so, I’m happy to say. 2022 represents the expected date by which there will be two complete browsers which have implemented every feature in HTML and have test code written for each of those features. That’s over 20,000(!) tests. Understandably, this will take some time. Most of the “core” features in HTML5 are already implemented in all the major browsers.

Enough history! What does HTML5 actually do? In a nutshell it provides a series of new tags which identify to browsers, robots and programs of all stripe what a particular piece of content means. Consider the example of the top navigation menu on a website. In HTML4 this is typically implemented as a series of divs, or possibly a table (gasp!).

These elements suffice to contain the content, but they do not convey the meaning of the content. In HTML5, on the other hand, you would wrap this navigation element in a nav tag. The nav tag indicates that these elements are not just a random collection of links on on your site, but rather, represent a logical unit of navigational data. Spiders, like Google and Yahoo can use this fact to understand the logical structure of the website. Tools can be written which automatically check your site for consistency and unnecessary (or broken) navigation elements. And browsers can provide tools to help user browse deeper into the site — opening each main nav link in a new tab automatically, for instance.

In addition to the nav tag, there are HTML5 tags for sections, articles, headers, addresses, asides and a host of other meaningful elements on the page. Each of these elements provides a way to create content which carries it purpose and meaning along with it. These core semantic markup elements are fully supported in Firefox and Chrome (and Opera, if anyone cares). Which brings us to Internet Explorer.

Internet Explorer has long been the problem child of web development. IE unfaithfully butchers most content and and has caused many a designer to swear a personal fatwa against the entire Redmond team. Fortunately, there’s a cure.

A free JavaScript library exists called Modernizr []. By simply including the modernizr.js file in the head of your web page Internet Explorer 6+ will properly interpret all of the common HTML5 markup tags, so your nav still provides navigation in IE.

HTML5 finally brings to web pages a robust mechanism for providing context and meaning along with their content. It’s supported anywhere. With the simple expedient of adding one or two tags to your existing pages you can say “HTML5? Of course I’m using it!”