HTML5: The 900-Page Gorilla with a Wide Ensemble

Like this article? We recommend 

With a 900-page specification, HTML5 is a daunting prospect for web designers. Fortunately Introducing HTML5 by Bruce Lawson and Remy Sharp is a more modest 224 pages of guidance for web developers.

Bruce Lawson is an Open Web Evangelist at Opera Software, and a member of the Web Standards Project's Accessibility Task Force. Remy Sharp is a developer and author, and expert in jQuery and Javascript.

Bruce and Remy are based in the UK, while I (Miraz Jordan) live in New Zealand. We chatted by means of a shared document.

Bruce and Remy are not only enthusiastic and knowledgeable about their subject, but are generous and kind too.

It was only half way through the interview that Remy mentioned one of his pet peeves: "It's 'HTML5' not 'HTML 5'." Oops. The following questions have been adjusted accordingly.

But then, the relaxed attitude is quite fitting, since one of the fundamental aspects of HTML5 is its forgiving and flexible nature.

Miraz Jordan: Can you explain in just a sentence or two what HTML5 is, and how it differs from XHTML or HTML 4?

Bruce Lawson: HTML5 is a set of developing standards for web applications. Its original name was Web Applications 1.0. HTML 4 is great for static documents, but for highly interactive JavaScript-driven apps it wasn't the best, because it wasn't designed to be.

HTML5 is not an XML language, so you get lots more flexibility with syntax. You don't need to quote attributes, some tags don't need to be closed or are optional. You always had this with HTML, but many of us who grew up with XHTML didn't know that.

If you want to use XML, you can use XHTML5, which has largely the same features but has a stricter syntax, must be served as real XML and so can't be rendered in IE8 or below.

Remy Sharp: I think the title of "HTML5" is actually quite misleading. Particularly as HTML 4 was primarily about the elements that make up a page.

HTML5 definitely takes that further and gives the author more semantics, but what HTML5 is really loaded with is JavaScript APIs.

I describe HTML5 as an iceberg, with the new elements as the top of the iceberg poking up out of the water, and the mass of JavaScript APIs sitting under the water.

HTML5 is pointing firmly towards Web Applications, and the APIs are the methods by which we'll apply all the Whizz Bang.

Lawson: Sharp always says that, just to make his part of the book seem more exciting than mine. Oh. It is anyway.

Jordan: What are the main points we should know about HTML5? What about it is 'special'?

Lawson: I'm a markup guy, so I'm very interested in the 28 new elements (or perhaps 29 — that bit of the spec is still in flux).

More tags means more semantics — unambiguously marking up what your content is — and that is generally a win for accessibility.

For example, a screen reader for a blind person could have a button for "jump to navigation" which would always work properly because in HTML5 we have a <nav> element that it would look for.

In HTML4, the software would probably look for a <div> or <ul> or <ol> with a class (or id) of nav or navigation or menu or sidebar or mainNav.

What's most amazing is that HTML5 tries to square the circle of developing the language for the future while "not breaking the Web". It defines error-handling so legacy content will work interoperably, while extending the language in a manner that can be feature-detected and faked in JavaScript.

Sharp: Gosh, "main points"? It's a 900-page spec bursting with technology and features — so it's a tough question to answer!

An author should definitely get cozy with the new elements in HTML5. It'll give them more semantics, which will let them be more expressive with their documents. But then, I'm a JavaScript guy, so it's the APIs that I find most special.

There's the drawing APIs, media APIs, history APIs, storage and more.

I'd actually strongly encourage authors to be aware of all the technology that's available to them. Not particularly know the APIs inside out, but know that they exist, like knowing there's a screwdriver in the toolbox that fits a particular screw. It's not that you use it all the time, but if you need it, you've got the tool to hand.

What's super important and different about the HTML5 spec, is that these APIs have been painstakingly speced out for the browser vendors.

This is important because it means no more discrepancies between browser implementations of particular APIs, and finally we can have certainty that there will be interoperability.

Jordan: My impression from the first part of the book is that HTML5 redefines how we think of a web page. In the past the 'page' was the defining unit, and it would be divided into various sections. HTML5 seems to turn that around and define base modules—sections—that are collected together into a unit then called a 'page'.

Lawson: Yup. But that's HTML5 reflecting how the Web has evolved. There are more and more "pages" that are actually applications. These are by no means the bulk of the Web, but most sites aren't hand coded any more — they're pieced together with Content Management Systems like WordPress or Drupal or the big enterprise beasts.

HTML5 defines a method of programmatically assembling an outline of pages in the browser, so that software like search engines, browsers and assistive technologies can make sense of them.

Sharp: Lawson is the best person to answer this. However, you've yet to get to the best part of the book — my chapters :)

Lawson: Whatever.

Jordan: Is HTML5 catching on?

Lawson: Like wildfire. When I was doing my markup for my website there was no information that I could find on the Web except for the spec.

Fortunately, I work for Opera, alongside many of those involved with writing the spec, so I could ask them for help!

Now there are loads of resources out there, including HTML5 Doctor which Sharp and I are involved with, that are devoted to helping people understand the language. Some resources, inevitably, are of lower quality than others.

We're seeing a huge increase in sites that claim to be HTML5. The best are showcased on HTML5gallery.com, run by Rich Clark (a fellow HTML5 Doctor).

Many "HTML5" sites aren't anything to do with the language; they're just JavaScript, or some proprietary CSS.

Some sites don't even attempt to work cross-browser, which is both misleading and lazy. While Opera began the work on HTML5, for the last three years all the major browser manufacturers have been collaborating on the development of the spec (see http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#history-1).

Sharp: HTML5 is definitely the buzzword for this era of web buzzwords — which is both good and bad. I've personally seen people confuse HTML5 with CSS3, with jQuery and even with web site hit counters!

The upside of all of this is that the message is getting out there that HTML5 is ready for day to day use.

Obviously I have a slightly biased view: I write for HTML5 Doctor (along with 6 fellow "Doctors" including Lawson), I run HTML5 demos, I speak to people who want to hear about HTML5 — so in my little world: everyone loves HTML5!

More seriously though, the stats on these web sites are actually quite telling.

Ever since Google announced their HTML5 video demo page, there was a big jump in traffic, and that's steadily risen. That alone says to me that the web community are keen to learn about this shiny thing called HTML5, even if it's just to benefit from the rich semantics it offers.

Jordan: What are some of the bigger websites using HTML5? Who's leading the field?

Lawson: My current favourite real-world site (that is, not a tech showcase or personal experiment) is the website for the government and President of Chile. It uses lots of new elements, and will grow to use interactive and multimedia HTML5 features too, such as <canvas> and <video>.

Sharp: Probably YouTube is the biggest site I know using—or rather experimenting with—some of the snazzier HTML5 features. Also Apple's me.com web app is making use of the offline cache store to give their site an extra whip out of the door.

It's important to realize that "using HTML5" is a loaded phrase. Since HTML5 is so big, it's likely sites will be cherry picking bits and bobs, the same way we do with CSS.

For example, Google's main homepage uses the shortened, versionless, doctype. That means their site is HTML5-ified. There's a lot and lots sites making use of little bits of HTML5.

Jordan: What part of HTML5 do you think is the hardest for most folks to come to grips with? Why?

Lawson: For those who are used to XML syntax, the perceived laxity of the syntax is a barrier. The outlining algorithm is hard to come to terms with: the idea that

<h2>A heading</h2>

<article>
<h6>Another heading</h6>
</article>

and

<h4>A heading</h4>
<article>

<h2>Another heading</h2>
</article>

and

<h1>A heading</h1>
<article>
<h1>Another heading</h1>

</article>

are equivalent!

Try pasting these into HTML 5 Outliner if you don't believe me! We talk a lot about this in chapter 2 of Introducing HTML5.

Sharp: I think the article element and understanding exactly when and where to use it is confusing to a lot of authors.

The problem, I think, is that the language creates preconceptions in our heads. A "div" never really made us think of anything in particular, so it's easier to learn the meaning.

"Article" and "section" mean particular things in the English language so it's contributed to a lot of confusion as to when exactly the article and section elements should be used.

Lawson: I agree with Sharp. The longest chapter in the book (and the best, because I wrote it) is the chapter that deals with the new semantics.

An analogy I like was given to me too late to make the book. Think of <article> not in terms of print, like "newspaper article" but as a discrete entity like "article of clothing" that is complete in itself, but can also mix with other articles to make a wider ensemble.

Sharp: There's also a few of the JavaScript APIs (actually the best part of the book, ignore what Lawson says). They're not particularly hard to master, but there's some subtleties.

Miss those subtleties and you might end the day wanting to throw your machine out the window. That's where the spec isn't completely obvious to authors, or maybe browsers haven't implemented the last 5% of some particular API.

Web Storage is a classic example of this. The spec says it can store any data type, whereas in practice the browsers convert the data type to a string.

Really that's what Introducing HTML5 is all about: taking the specs and digesting them in a form that we authors can understand and use today. We hope to save a computer or two from being thrown from a window.

Jordan: What has been your personal biggest challenge with HTML5? And what is your pet peeve with it? Why?

Lawson: The biggest challenge for me was giving up the perceived purity of XML.

My main gripe is the unnecessary crippling of the <time> element, which can be used to unambiguously mark up dates and times:

<time datetime=2010-08-22>The Feast of St Taneesha and the Immaculate Surfboard</time>

This would be great for microformats, history web sites etc. — but unfortunately, you can only use it with precise dates and times.

So you can mark up 13 October 1925 but not October 1925. You can't mark up ancient dates either, so Julius Caeser's death on 15 March 44BC can't be expressed in HTML5.

I think that's silly (and if you do too, add your voice to the Wiki.

Sharp: The biggest challenge for me was really just digesting the whole of the HTML5 spec and the related JavaScript specs (Web SQL Storage, Sockets, Geo, etc.).

There's a lot of new APIs available and tons to play with — writing the book was a perfect excuse to wrangle these specs to the ground.

My pet peeve? Probably that it's so easy for people to ask "when will HTML5 be ready?".

It's a perfectly fair question, but I think it's the way the spec is constructed that makes people feel like there should be a point at which it's "done".

I think that the spec could have been split out in a similar way that CSS3 is broken into modules. That way authors would be more secure in their decisions as to which modules are complete and usable.

The truth is, you can just cherry pick the bits you want to use. Some parts of HTML5 have superb support reaching back to IE5 days, other parts are only in the latest nightly beta releases. It really depends on your application and the audience.

Jordan: What's your favorite thing in HTML5? What does it do, and why do you like it?

Lawson: I like the relative simplicity of the APIs (except the Drag and Drop API, which is horrible for historical reasons). I'm no JavaScripter, but even I can understand them.

Mostly, I like the way that most things you want to do are now folded into the HTML5 standard, so there is an Open Standard alternative to proprietary plugins for most use cases.

Plugins will still be required for some uses, such as DRM video, capturing data from a user's camera or microphone, as well as to render existing content. Many uses will continue to use plugins but at least now developers have a choice.

A professional developer chooses the right tool for the job: sometimes that will be native HTML5, sometimes it will be plugins. But at least there is that choice now.

Sharp: A tough question. Choosing a favorite HTML5 feature is like choosing your favorite cat. You love all of them, regardless of the thick one that has no balance (see Drag & Drop — chapter 8!) or the smarty that can open the fridge door (see Offline cache — chapter 7).

They're all fun to play with, and if the problem is right, the APIs are a perfect fit.

If I were to choose two that I'd absolutely not want drowned in a plastic bag, it would probably be the offline cache and Web Sockets (not actually part of the HTML5 spec, but included in our book).

Those APIs, along with others, really open the door to a fully immersive application experience on the web. Using web apps without the web, and easily integrating real-time data using just JavaScript is a very exciting prospect indeed.

Jordan: What are the current challenges you see for HTML5?

Lawson: The main challenges are for browsers to implement the specification, and for developers to ensure that they use HTML5 properly.

For example, we see lots of examples of people using HTML5 <canvas> for graphing information, even though the right tool for the job is the W3C graphics spec, SVG.

We've seen a lot of coding for specific browsers, even from developers who should know better.

This sort of nonsense is likely to inhibit adoption, if IT directors and managers see all kinds of impressive demos and sites that can't be used on the browsers that people really have on their smartphones and desktops at work.

Sharp: Absolutely what Lawson said. It's really important for authors to know what the right tool is for the right job.

I'd also add the accessibility aspects need to be ironed out in some of the parts of HTML5.

For example, a standardista may say it's bad practice to build a site entirely in Flash, but using a <canvas> element is exactly the same bad practice and has the same accessibility issues.

This whole area is being explored and solved as we speak.

Jordan: It seems HTML5 isn't really ready for general use yet. If we want to start experimenting with HTML5 for ourselves as we read your book which browser do you suggest we start with, and why?

Lawson: You can use some of HTML5 now, like you can use some CSS3, but it won't all work everywhere. Professional developers know that, and have lived with that for years.

Use all the browsers regardless of what your favorite is, so you know what works where. You're a web developer, and you are not your visitors or your clients' customers.

If there's a lesson that HTML5 coders can adopt from usability practitioners it's "you are not your user".

Sharp: I wouldn't agree that "HTML5 isn't ready for general use." This was the point I was making before, "HTML5" is being lumped in to this term that contains everything.

If you want to make your web site HTML5-ified: simplify the doctype. That's all you'd need to pass the HTML5 validator (assuming your HTML4 or XHTML was valid in the first place).

There are parts of HTML5 that are very, very well supported (going back, as I said, to IE5). If you've used Flickr to upload photos, you'll be familiar with the editable title on the pictures. This could be done using contentEditable an "HTML5 feature". This has been around for a long time.

So do start experimenting, and release to your production environments and you'll happily see that HTML5 is ready to be used today.

Regarding which browsers to experiment with, if you're keen on the sexier features of HTML5, well, it's really up to you.

Last year I might have said all of the browsers bar IE — but today, IE9 preview release is available, and that has some fantastic HTML5 support. So you can pick and chose your browser. The Big Five have great support, not 100%, but again, I think HTML5 should have been modularized!

Jordan: What do you see as the biggest 'selling point' for HTML5?

Lawson: That web applications will be easier to code for developers, and more robust with no "upgrade your plugins" messages for the consumer.

Sharp: The "baked in the browser" bonus. The fact there's no plugins required to get going with this technology is a huge bonus.

Remember the APIs are more than just HTML5. There's technology baked in to browsers like geolocation, Web Sockets, file manipulation via the File API. And in some of the beta browsers we've got the 3D WebGL APIs — all of which are done without plugins, no upgrades required and can all be developed using a simple notepad application. No compilers, no build time, just you, your notepad app and the browser.

Jordan: I use WordPress for my own sites and for clients. Why should I care whether WordPress moves to HTML5 or not?

Lawson: You shouldn't. WordPress is a blog, not an application, so for the moment, there is no advantage to using HTML5.

When assistive technologies start being able to take advantage of the new elements, you can just grab my HTML5 theme and away you go.

Sharp: Basically: what Lawson said :)

Jordan: Is there anything else you'd like to say?

Lawson: Don't go all crazy and start using HTML5 for everything. Your HTML4 and XHTML 1.0 websites will continue working forever.

Of course, if a customer demands an HTML5 website, because he's heard the buzzword and doesn't have a clue, just put an HTML5 doctype on the current site. Then, hey presto, he's got what he wanted with no extra work! Just pocket the extra cash and send us 10%.

Sharp: Explore! If you're interested, have a play. It's how most developers learn the technology, so play and experiment. Once you have, you know what the browser is capable of, and then you'll know when to use particular parts of HTML5, or parts that aren't HTML5 — but you'll know the technology exists.

Remember: use the right tool for the job. Don't go using "HTML5" just because it's a buzzword — use the technology for its strengths. Make sure you've considered both <canvas> and SVG before making the decision.

Oh, and buy Introducing HTML5 because you'll be instantly be more attractive to the World since you'll be all HTML5-ified.

Jordan: Thanks Remy and Bruce for sharing your thoughts.

© Copyright Pearson Education. All rights reserved.