HTML5 by Ben Frain
I wrote a version of this piece originally for MacUser in 2009. Whilst most of it still stands, if it’s of interest, take a look at my book ‘Responsive web design with HTML5 and CSS3‘ as there is a far greater level of detail in it, practical examples and a lot more current ‘best practice’ methods of dealing with Old IE.

HTML5 is the successor to HTML 4.01, the language most web pages on the Internet are written in. HTML5 offers new semantic elements, direct support for video and audio, built-in form validation and a smart new canvas feature. In this article I’ll attempt to explain what’s important about HTML5 and what you need to know to start using it.

HTML specifications are set by the World Wide Web Consortium (W3C for short). It’s their job to develop draft proposals for new specifications then test and ratify them into standards. Sadly, this process is a lengthy affair; proposals pass through various stages of review and revision before the W3C eventually endorses them as web standards.

Although the full specification of HTML5 is yet to be ratified, new features of HTML5 are already being supported, to varying degrees, by current web browsers including Apple’s own Safari, Google Chrome, Opera and Mozilla’s Firefox. So, whist it’s improbable everything in the current draft of the HTML5 specification will survive until recommendation by the W3C, there are plenty of new features that can be implemented right now. Here we’ll take a look at these new features, the benefits they offer and why you might consider using them on future web projects.

HTML5 evolved from the Web Applications 1.0 project, started by the WHATWG (Web Hypertext Application Technology Working Group) group before being later embraced by the W3C. Subsequently, large parts of the specification are weighted towards dealing with web applications.

Despite this, the HTML5 specification does provide some interesting new elements that potentially improve the structure and semantics of the code used to build everyday web pages. To illustrate the improvements, consider that using existing HTML 4.01 code, sections within the of a web page are structured using

tags. These tags can have an attribute e.g. ‘class’ or ‘id’ and a value, defined in quotations. For example, the tags for a block of navigation links might look like this:

nav link1 nav link2

However, although a human reader of the code can ascertain what that div represents (a block of navigation), a machine cannot. This is because HTML 4.01 doesn’t include elements that more accurately describe the specific structures within a current web page. To illustrate, using HTML 4.01, a simple web page source code might look like this:


< !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

	
		All about HTML5
	
	
	
	
	
	

About our articles

And more importantly, why you want to read them

section content

header of the article here
The actual article contents

Whilst the div’s can be named, there is no standard naming convention so it’s impossible for any div to be automatically understood. Conversely, the HTML5 specification introduces a number of new section elements that allow the contents of web pages to be more accurately (semantically) described. These new section elements include <section>, <nav>, <article>, <aside>, <header>, <hgroup> and <footer>.

The <section></section> element is used to define a section of related content and should usually include a header. The HTML5 specification advises,

“…examples of sections would be chapters, the various tabbed pages in a tabbed dialog box, or the numbered sections of a thesis”.

The <nav></nav> element should be used to wrap a section of navigation links. These should be for other inward links such as home, contact, blog etc or for linking up sections of a large page such as a table of contents.

The <article></article> element defines an independent part of a website; something that could be used ‘standalone’, such as a cooking recipe or a product review (or a blog post like this – which is how I’ve used it).

To separate things like advertising, quotes or nav sections from the main content of a site the <aside></aside> element can be used. Typically the <aside></aside> element would be used for sidebars and the like. Essentially, content tangentially related to the main content.

The <header></header> element, like the <footer></footer> element can be used multiple times within a page. It is intended to be the header of the section it is used within so can live within elements like <section></section> or <article></article>. The header element can optionally include the <hgroup></hgroup> element which is used to include a hierarchical group of h1h6 tags, for example an article’s title and then sub-header.

The <footer></footer> element is one element that is potentially confusing. Ordinarily, it may be assumed that each page would have just one footer, visually appearing at the bottom of the page (including a mini site-map or contact details for example) but in HTML5, footers, like the header element, can appear any number of times within different sections or articles. The specification notes that the footer element should be:

“a footer for its nearest ancestor sectioning content or sectioning root element…”

The footer element could therefore be used to provide information about the section or article it belongs to, for example to contain details about the author of an article.

Therefore, by using these new elements, the same page written in HTML5 might look like this:

< !DOCTYPE html>

	
		All about HTML5
	
	
	

About our articles

And more importantly, why you want to read them

section content

header of the article here

The actual article contents

The article footer
Here is the page footer

Besides being easier for humans to interpret the code and its intended structure, it’s easy to appreciate how these new semantic elements will aid search engines and the like find and rank the actual content of a page. For the latest guidelines on when and how each of the new semantic elements should be used, refer to the latest draft of the HTML5 specification.

Whilst reading the HTML5 specifications is useful, those short on time may find it more informative to de-construct existing web pages to see how the new code works in practice. Thankfully a website exists showcasing web sites built using HTML5. Visit http://html5gallery.com to see how the new HTML5 section elements are being implemented in real world examples.

A Fly-IE in the ointment
Before rushing out to implement HTML5 in a design it’s worth mentioning two words that cause many a web designer to convulse: Internet Explorer. Sadly, at present, Internet Explorer 8 and below, offer no support for any of the new semantic HTML5 section elements discussed. However, for those wanting to implement HTML5’s semantic section elements now, there is a workaround.

Currently Internet Explorer ignores the new section element tags and therefore fails to render them. However, JavaScript can be used to effectively ‘teach’ these elements to Internet Explorer so it renders them correctly. A free to use ‘HTML5 enabling’ script, produced by Remy Sharp, is available at: http://remysharp.com/2009/01/07/html5-enabling-script/. Using this JavaScript adds all the current HTML5 section elements to Internet Explorer. However, these days, it makes much more sense to use Modernizr, which includes this polyfill shim and a whole lot more.

New audio and video tags
Ordinarily, with HTML 4.01, adding video or audio to a web page is far from an exact science. Viewing the resultant media is always reliant on some form of browser plugin. HTML5 aims to remedy that situation with simple <audio></audio>and <video></video> tags that allow media to be directly inserted into a web page.

The original specification for HTML5 called for all browsers to support the direct playback (without plugins) of video and audio inside ‘Ogg’ containers. However, due to disputes within the HTML5 working group, the insistence on support for Ogg (including Theora video and Vorbis audio), as a baseline standard, was dropped by more recent iterations of the HTML5 specification. Therefore at present, Safari only allows media with the .mov extension to be used with the <audio></audio> and <video></video> elements whilst Firefox and Opera only support Ogg. Hopefully these shortcomings will be addressed in due course.

In the meantime lets look at how the audio and video elements work by viewing the Safari welcome page at http://www.apple.com/safari/welcome/.
On first glance, it’s logical to assume the short introductory Safari video and accompanying music were incorporated into the page using Flash or a similar browser plugin. Instead, they have been implemented using HTML5. View the source of the page (from the Safari tool bar choose View and then View Source) and it’s possible to see how the short video was included:

A breath of fresh air for most web designers! Rather than the abundance of code currently needed to include video in a page, HTML5 allows a single tag to do all the heavy lifting. It’s also possible to insert text between the opening and closing tag to inform users when they aren’t using an HTML5 compatible browser e.g.


Besides the source of the video and the dimensions (as seen in the Apple example), additional attributes include ‘autoplay’ to play the video as soon as it is loaded, ‘autobuffer’ to automatically load but not play the video, ‘controls’ to add personalised play/stop buttons, ‘loop’ to repeat the video and ‘poster’ to define a ‘poster’ frame of video, useful if there’s a delay in the video playing. To use an attribute, simply add it to the tag. Here’s an example including the loop attribute:


The <audio></audio> tag works on the same principles with the same attributes (minus width, height and poster).

Form validation
Another boon for the average web developer is that HTML5 has built-in form validation. Without the need for JavaScript, PHP or similar, standard form <input /> elements can be validated within the browser (currently only Opera 9.5 and above supports the HTML5 form validations fully). HTML5 includes (amongst others) input types for number, date, email, range and url. So, for example an input field may look like this:

 

Fully HTML5 compatible browsers would automatically validate this input field and any value that wasn’t between 18 and 65 would be rejected. Furthermore adding ‘autofocus’ would focus the browser on that field initially and ‘required’ would indicate that the field is required to be filled.

Canvas
The <canvas></canvas> element is an HTML5 element used to add a blank canvas to a web page. Using JavaScript it’s then possible to add all manner of interactivity to this canvas. Within a webpage a canvas is added simply like this:

Whilst the element can be styled like any other element using CSS, it is recommended that dimensions of the canvas are included within the tag. Like the <video></video> element, anything added between the opening and closing tags will appear in non-HTML5 browsers.

The element is currently supported in Chrome, Opera, Firefox and Safari. For a highly detailed explanation of how to implement the element and more on the vast possibilities it provides, head over to Mozilla’s own canvas tutorial: https://developer.mozilla.org/en/Canvas_tutorial

Conclusion
Whilst there are many proponents endorsing the new features of HTML5, there are perhaps just as many vehemently opposed to it. As the specification is still in a state of flux, it’s still possible to provide feedback on its development; head over to the W3C site to air your thoughts on the next version of HTML. Alternatively, for those who want to get cracking, download the latest draft of the specification and get using HTML5 today.