Getting ready for HTML5

Posted by Adrian Fri, 03 Jul 2009 22:01:00 GMT

With the recent round of browser updates, HTML5 is almost ready for prime-time. If you're a web developer, you should start preparing for the changes now. In this article (which may become a series of articles), I'll explain what's coming/here now.

If you read the popular tech news sites you'll probably already know that HTML5 comes with handy a handy <video> tag, timed media playback (a la Flash), off-line storage and a canvas tag. These are the changes that will certainly have the biggest impact, but HMTL5 will bring quite a bit more than that to the table.

I say will bring (future tense) rather than brings (present tense) on purpose. The current crop of browsers have very selective HTML5 support.

The Doctype

One of the changes that has been introduced is a new doctype and simplified meta tags for declaring the charset. This is great, because every time I start a new project I have to go and hunt for a doctype to use. This is HTML5:

<!doctype html>

Seriously! That's it. That will also, rather cleverly, be the doctype for HTML6 and beyond. The idea is that HTML specifications will be written in such a way that older browsers will degrade gracefully and in a very predictable manner when they encounter an element they don't understand. This is a very noble goal, and I really hope it works out.

It's also worth giving a quick example of the lang and charset declerations in HTML5:

<!doctype html>
<html lang="en-US">
<head>
  <meta charset="utf-8">
   ...

Semantic Mark-up

One of the goals of the HTML specification writers' has, for a long time, been to provide better mechanisms for making tags describe semantic elements of a document, the idea being that stylesheets would allow us to transform plain, semanticly-laid out text as beautifully presented data.

That dream took a big step forward when HTML4 was banished and XHTML became king. XHTML's authors made it clear that tables were for describing tabular data, not for making columns or headers. We all struggled to get to grips with some of the quirks of CSS, but we are there now - we can quite easily lay-out a print-quality design using largely semantic data and CSS.

While undeniably the right thing to do, this has lead to our documents becoming collections of meaningless <div> and <span> tags. This isn't a major issue for graphical browsers, but what if you want to automate the processing of a website and extract as much information as possible about the content without knowing anything about it ahead of time. For example, you couldn't process the links in a complex page and know which were intended purely for site navigation and which were part of the content.

So the first change in HTML5 that we'll discuss are the new tags. The most interesting include:

header
nav
section
article
footer
address
dialog
dl

Probably the only tag that makes no sense just reading it is dl, which is 'description list' (for describing terms and definitions). Address is also worth a quick note -- it isn't for postal addresses in general; it's purely to tag contact details for the 'page'. For example, if this page had an address tag, it'd go around my name and email address.

The header, nav, section, article and footer tags in particular, I believe, will be block-level elements. That is, they will behave exactly like div tags. Unfortunately, because none of the current browsers understand the HTML5 doctype, they don't know what to do with the tags and they default to being inline elements.

You can work around this in FF and Safari by declaring the tag as a block level element in your CSS:

<style type="text/css">
header { display:block; }
section { display:block; }
etc...
</style>

The only modern browser line that won't style these new tags with just the above CSS is Internet Explorer. However, it seems there's a kludge that will make it work -- in a script tag you need to create a dom level element for each of the types of tag you will use and will need to style. E.g.,

<script type="text/javascript">
document.createElement('header');
document.createElement('section');
etc...
</script>

I haven't actually tested this myself in IE, but I understand it'll work in IE6+. That tip, by the way, I found on http://www.css3.com/.

So what will a HTML5 document look like? Well, let's imagine a typical layout with a header, a tab bar, a navigation panel down the left, an article with several sections and some authorship information.

Such a template might look like this:

<header>
  <h1>ACME Design</h1>
  <ul id="tab-bar">
    <li><a href="#">home</a></li>
    <li><a href="#">about</a></li>
    <li><a href="#">contact</a></li>
  </ul>
</header>
<nav>
  <h2>Related Content:</h2>
  <ul>
    <li><a href="#">Another Page</a></li>
    <li><a href="#">Another Page</a></li>
    <li><a href="#">Another Page</a></li>
  </ul>
</nav>
<article pubdate="2009-01-07T21:09+01:00">
  <section>
    <h1>Article Section Title</h1>
    <p>Blah blah blah</p>
  </section>
  <section>
    <h1>Another Section</h1>
    <p>Yada yada yad</p>
    <aside>Information not directly part of the section content, but loosely related</aside>
  </section>
</article>
<footer>
  Copyright + footer links
</footer>

Now, one thing that surprised me in the HTML5 spec is that the tab-bar and footer links aren't inside separate nav elements. Here's what the W3C say about it:

The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links. Not all groups of links on a page need to be in a nav element — only sections that consist of primary navigation blocks are appropriate for the nav element. In particular, it is common for footers to have a list of links to various key parts of a site, but the footer element is more appropriate in such cases. [http://dev.w3.org/html5/spec/Overview.html#the-nav-element]

There's also a second ambiguity -- it seems that the header should really only contain one header element (I.E., an h1), and that if you have more than one header element, they should be in a hgroup tag that is inside header. That's a bit of a grey area for me, not least because some of the official HTML5 code samples put links and such like in the header element (as I have done above). Hopefully it'll become clearer when people start really adopting HTML5.

Hopefully the above example will give you an idea of the most important tags that will become the norm for nearly every HTML page in the not-too-distant future. I really like the descriptiveness of the HTML source with these new tags, so I think it's a very good thing.

New Form Elements - Web Forms 2.0

This is quite an exciting development, but sadly only one of the current-generation browser engines supports any of the new tags and attributes (in case you are wondering, it is Opera) so this is all still some way off.

There are two new elements:

<datalist></datalist>
<output></output>

Datalist is set to replace table as the preferred method of display the results of dynamic data queries, with tables being used for static tabular data only. Output is just a semantic tag that marks a block of content as being the output of whatever is being described (for example, program output if talking about a command line utility). Datalist is not yet supported by any browser.

There are quite a few new input type options:

datetime
datetime-local
date
month
week
time
number
range
email
url
add
remove
move-up
move-down

Those are quite exciting for no reason other than it will hopefully make form validation in JavaScript almost non-existent -- especially when paired with the new attributes that can be applied to input tags:

min
max
step
pattern
required
form
autocomplete
autofocus
inputmode
list
template
repeat
repeat-min
repeat-max

autocomplete is already widely implemented (as a privacy feature), but now it's official. autofocus is a great addition that is long over-due. Required and pattern are also pretty exciting. Hopefully nearly all of our client-side form validation can be described by attributes once HTML5 is widely adopted.

Cross Document Messaging

This feature is ready to use now in all current browsers apart from Opera. If you have a frame, iframe or popup window you can use it's handle and call postMessage to raise an event in the remote page. This appears to be an answer to the cross-site scripting issues that now have lead to restrictions on doing this using current Ajax tools. Hopefully it won't lead to lots of new cross-site-scripting vulnerabilities - I haven't checked the restrictions around sending cookie contents to remote domains in an iframe that has been generated by naughty un-escaped user-input, but I suspect it is all taken care of.

Here's an example of sending a message between two pages -- the first function would be on a page that is loading the second page in either a frame or a new window, and posts a message to on some event, maybe a button click. Note that the second parameter ('*') of postMessage is target-origin (i.e., the domain name of the target page). * is a wildcard, so no check is performed, but in the real world you would set it to the expected domain, for added security:

function sendMessage()
{
  var iframeEl = document.getElementById('myIFrame').contentWindow;
  iframeEl.postMessage('message text', '*');
}

The receiving page will need to register a handler for the 'message' event on the window object. The handler function receives event args, usually defined a 'e', and this has origin and data properties. Origin is the originating domain name, so we can validate that we trust the sender:

window.addEventListener('message', onMessage, false);

function onMessage(e)
{
  if (e.origin == 'mydomainname.com')
  {
    alert(e.data);
  }
}

Video and Audio tags

These tags will one day make embedded media a breeze, though for now limited codec support means Flash video will probably still be the most popular way to add video to a web page.

The video and audio both accept a controls attribute, to toggle the browser-default playback buttons. A src tag is used much as with images. You can add width, height and poster attributes to videos -- poster is used to display an image while the video loads.

Here's an example of both tags in use:

<video src="movie.ogv" controls poster="preview.jpg" width="640" height="400">
    <a href="movie.ogv">Download</a>
</video>

<audio src="song.mp3">
</audio>

As you can see in the video tag, you can provide additional html content - commonly a download link.

Another useful feature is the ability to supply multiple sources:

<video controls poster="preview.jpg" width="640" height="400">
  <source src="movie.mp4" type="video/mp4">
  <source src="movie.ogv" type="video/ogg">
</video>

The final, and potentially most exciting and useful feature is Javascript control. If you give your media tags an id, you can create a reference to them to call playback functons and respond to playback events:

var media = document.getElementById('welcomevideo');

function rewind()
{
  media.currentTime = 0;
  media.play();
}

In progress

Sorry, this article is taking way to long to write. I've still got off-line storage to discuss and I want to include a comprehensive list of new tags and features, maybe in a fancy PDF fact-sheet. I'll try and add these things by the end of this week...

About

We are a small British company that produces business-oriented software and solutions. These articles are a product of our daily work - information that we think might be useful to share. We hope you find them useful.

Our Software

These are some of our products. Several are open source, some are web-based and others are proprietary:

Syndicate

Articles

Component Workshop Ltd