15 Nov 2010

This is a transcript of a presentation I held recently concerning my visit to the Fronteers 2010 conference.

Visitors included, amongst others, my heroes Håkon Wium Lie, Peter Paul Koch, and Anne van Kesteren. Fronteers is the dutch organisation for front-end web development. This article is mostly based on the following talks:

  • The Design of HTML5 by Jeremy Keith
  • JavaScript - Like a box of chocolates by Robert Nyman
  • Reusable Code, for good or for awesome! by Jake Archibald
  • A CSS3 talk by Håkon Wium Lie
  • CSS Workflow by Jina Bolton
  • Progressive Downloads and Rendering by Stoyan Stefanov

Due to some special effects, this article is best viewed in Opera 10+, although fallbacks are available for other browsers (not IE, I said "browsers").

This article is heavily biased, but that is my opinion, not that of the authors of the talks mentioned before.


In the early nineties the first HTML spec, being HTML 2.0, was published. The development on the spec stabilized quickly, at least quickly in the market of specs. In 1997 HTML 4.0 was introduced and in 1999 HTML 4.01. This was the last spec for HTML that the W3C published, although it is quite commonly found in use today.

The W3C opted for something less lenient in coding style and introduced the XHTML 1.0 spec in 2000. Semantically it is nearly identical to HTML 4.01, but it requires a much stricter coding style, since it is an XML serialization, with all the pros and cons of XML. I like XML, so I use XHTML 1.0 Strict. Because it is more strict, it gives you more handles for consistency, making your code easier to maintain. Also, you can use a DTD to validate it, although more recent developments seem to think that is a bad idea (see What’s wrong with DTDs?)

The next spec was XHTML 1.1. Although it's differences from XHTML 1.0 Strict are minor, the fact that the server must serve it to the browser as application/xhtml+xml or application/xml and not as text/html, makes it practically inusable. For two reasons. First, IE only supports documents served as application/xhtml+xml or application/xml from version 9 onwards. This means the larger part of browser users won't be able to view a truly valid XHTML 1.1 document with their default browser.

Second, even when using a browser that does understand application/xhtml+xml or application/xml, you'll be exposed to the full blown mindnumbing force of the XML Error Model, which means as much that you'll be seeing a lot of this:


You might think "OK, so make validate XML documents, and the browser won't cry and break down. Suits you right for being so lazy!" But please note that if content is injected in any way, e.g. from a CMS, that might leave a stray unescaped & somewhere and you're dead. Our at least your site will be. The two of which may coincide depending how strict your boss validates you.

The W3C continued to work on the XHTML 2.0 spec, but never finished it. Conceived by briljant minds it suffers the fate of being practically unusable. Instead, the WHATWG started work on the HTML5 spec and suggested it to the W3C. So that spec has both the W3C and WHATWG working on it. It's not finished yet, but it offers an interesting new approach. The first being the design principle of Priorities of Constituencies:

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.

In other words, we (as webdevelopers) are important! If it is far easier for authors if the implementors handle some element in another way than they would like, we should get the priority. HTML5 is pragmatic by design.

Let me mention too, that the term HTML5 is being abused in the same way as Web 2.0 and AJAX used to be. I'm talking about the spec HTML5 here, not just "doing anything cool in the browser" (OK, I blatantly stole that line from Jeremy Keith).

So, HTML5 is pragmatic. What does that mean in practice? Let's take a look at the XHTML 1.0 Strict doctype declaration:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

DTD's can be used to validate the document. But, this is not something you typically want your browser to do. In fact, the only reason the doctype needs to be in the document is because someone thought it would be a nice flag to require if one wants to enforce strict mode. To make it worse version 6 of a certain browser doesn't allow the XML declaration before a doctype to trigger Strict Mode. Fortunately, XHTML 1.0 Strict allows the XML declaration to be ommited, as long as the encoding is UTF-8 or UTF-16.

So the doctype is still needed, but in HTML5 it is as short as possible:

<!DOCTYPE html>

The same goes for the encoding declaration. Compare XHTML 1.0:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

to HTML5:

<meta charset="UTF-8">

Looks good, huh?

There is also an XHTML serialization of HTML5. It is just as strict as XHTML 1.1 and it should be served XML. So it is not recommended for IE before version 9. It is recommended to use the stricter XML coding style, but serving it as XML, will prevent it from being rendered in IE < 9. If you're really bent on serving XML, you might want to take a look at polyglot documents.

Another pragmatic aspect of HTML5 is the support for fallbacks. Consider the new video tag. It works just like the img tag to embed videos:

<video src="movie.ogg"/>

But to provide optimal backwards compatibility, it can also be used as such:

  <source src="movie.mp4"/>
  <source src="movie.ogv"/>
  <object data="movie.swf">
   <a href="movie.mp4">download</a>

It will first offer an h264 encoded version of the movie, as a fallback for that an Ogg Theora video, as a fallback for that a Flash movie, and if all else fails, a download link.

HTML5 also introduces some new semantic elements. So the ubiquitous <div class="header"> can be replaced by the semantically much more pleasing <header>. And what's more, if you want to use it in old versions of IE, you can use the Modernizr javascript library. It will register certain elements, e.g. <header>, so you can format them with CSS.

There are also new input types. Try to count the times you needed a date field and had to format it using CSS and JavaScript. Well, now we have <input type="date"/></span>, behold:

You should be seeing something quite spectacular above. If you're using Opera 9+. Otherwise, it just falls back to <input type="text"/> so you can format it with jQuery or something.

So, even though HTML5 is still a draft at this moment, it's already usable. If you're running XHTML 1.0 Strict at the moment, it's just a matter of slimming it down and using the new elements.

You may also be interested in the related articles on javascript and css.