Notes on HTML 5

Thursday, January 24, 2008

I remember when Netscape 1.1 came out. Background colors were the big new thing. You could suddenly change the background color of your web page. Red. Blue. Black. Amazing. I remember when “tables” first came about: 1996 — about the same time I landed my first big web contract. HTML 3 hit soon thereafter. Then in 1998, HTML 4. 1998. XHTML 1.0 came about a few years later, but the changes were negligible (especially compared to the craziness of the mid-to-late 90s).

So in a very real sense the most basic technology of the World Wide Web — the HTML specification itself — has remained essentially unchanged for about ten years. CSS has become widely used, which is great. And “dynamic web” techniques with Javascript, AJAX, and such have become quite popular. So the web has changed. But HTML itself remains a bunch of <body> tags and <div> tags and <p> tags and <a> tags, etc… The same old pig underneath all of that fancy new make-up.

So here comes HTML 5, a new draft specification from the W3C. (I’m specifically looking at this document.)

Okay. Cool. Just hearing the term “HTML 5” brings to mind changing the way HTML works to fit the way we make and use the web today. So much of the day-to-day of web development involves awkwardly fitting new ideas into the increasingly creaky structures of HTML 4 and XHTML, even if most web people have become so used to this that they don’t even really consider it an issue anymore. Think, for example, of how one makes navigation on a web site. A developer must either appropriate <p> or <li> — for tasks they were not designed for — or they must use completely vague semantic tags such as <div> or <span>. Clunky. To say the least.

(Using the <table> tag for layout purposes is another prime example, even though most web developers no longer do this. The <table> tag was designed for displaying tabular data.)

Five years ago I wrote up my impressions of the XHTML 2.0 working draft. That document included many suggestions, including a navigation link tag (<nl>) and a new <section> tag to make page organization easier. And these (and other ideas in the draft) were great. But. They were merely incremental changes and fixes from the previous specifications. They didn’t address the semantic web very deeply and the specification has stalled. XHTML 2.0 is still just a working draft. It has changed quite a bit since I wrote about it, but doesn’t appear to have been touched much since the middle of 2006.

Semantic HTML and More

HTML 5 attempts to take semantic layout to all sorts of new extremes. (I’m looking at this doc about the differences between HTML 4 and HTML 5.) Look at all of the new structural elements:

  • <section>
  • <article>
  • <aside>
  • <header>
  • <footer>
  • <nav>
  • <dialog>
  • <figure>

Wow. Now we’re getting somewhere. The only major thing that seems to be missing as I look at it now is an <advertisement> tag. Imagine how easy it would be to automate translating web pages for mobile devices (for example) if they were all properly marked-up with tags such as these?

(Interesting to note: They reached this list in part by looking at Google’s web authoring stats, which Ian Hickson (quoted below) also developed, and seeing what people were already using. Clever!)

Besides the <advertisement> tag, what this collection appears to miss are structures that would be used with web applications. These are great for articles and papers. But now we’re all very used to apps like Facebook or Basecamp or Gmail which are most definitely not about presenting info that way. They’re dashboards and data views.

A List Apart further discusses and explains these semantic changes.

HTML 5 also appears to want to make life easier for developers. Take, as a quick example, the “ping” attribute for a link. This is an amazingly great idea. It invisibly (to the user) tells the browser to “ping” (notify) another script or page when the user clicks through a link. This could make tracking user activity much easier and save us from the obnoxiousness of all of those click-through and redirect URLs that we have to go through when clicking off of sites like Fark that want to know where we’re going. It also saves us the headache of that silly image or iframe trick for keeping track of web usage stats. Good.

The draft also describes much more flexible forms, scoped CSS styles (finally), and upgrades to the DOM (document object model) which would made dynamic Javascripting somewhat easier and more intuitive. Wonderful. There’s also some repetition and event-handling stuff in there which I don’t fully understand. I also haven’t read up fully on the new APIs for client-side storage, drawing, networking, and media playback — although integrating these elements more tightly into HTML seems like a good step for standards. The easier it becomes to do these things, the more people will play with them and make cool(er) stuff with them.

Another interesting addition are the <audio> and <video> tags for embedding media. If they can streamline the still amazingly clunky way we embed media, then make it so, Number One.

Slimming Down

The HTML 5 draft also strips away some fairly major parts of HTML 4. Including (drumroll, please) frames — the decade-old bane of usability and accessibility designers. I have a hard time believing that this will end the use of frames entirely, though. They’re still quite common they do have their use. And iframes will stick around, it appears. The draft also drops some other tags (and attributes) I’d basically forgotten about such as <big> and <dir> (directory).

Additionally, they are stripping everything having to do with presentation. No more “align” attribute. Not more “background” in your <body> tag. “Height” and “width” attributes look like they’ll also basically disappear. Bam.

Good! Frankly. If we’re going to split the content and presentation once and for all, then let’s just do it. We’ve been talking about it for over a decade. Although, again, I think breaking developers of their habits will be difficult enough — even those who want to write HTML 5-compliant mark-up — that browsers will still have to pay attention to those attributes. The same way browsers still know the <font> and <blink> tags. (Yeah, that’s right: I used a blink tag. I went there. And I loved it.)

And, again, I’m all in favor of seeing the HTML part of a web site become a very slim, streamlined, and very semantic sort of affair. The less crap, the better. Everything in it’s right place. Design in CSS. Content in HTML. It’ll make data portability much easier and will allow services such as Google which rely on semantic parsing to do a better job or what they do.

You get the idea. If you want to know the fine details, go read the docs.

Coming Soon?

So. XHTML 2.0 has been floating around in draft mode for at least five years. But today it seems relatively dull and incremental. HTML 5 has some exciting new ideas, though we have a wait before we see an HTML 5 web. WHATWG, the group spearheading HTML 5, say:

“It is estimated by the editor that HTML5 will reach the W3C Candidate Recommendation stage during 2012. That doesn’t mean you can’t start using it yet, though. Different parts of the specification are at different maturity levels. Some sections are already relatively stable and there are implementations that are already quite close to completion, and those features can be used today (e.g. <canvas>). But other sections are still being actively worked on and changed regularly, or not even written yet.” - WHATWG (source)

And:

“It is estimated, again by the editor, that HTML5 will reach a W3C recommendation in the year 2022 or later. This will be approximately 18-20 years of development, since beginning in mid-2004. That’s actually not that crazy, though. Work on HTML4 started in the mid 90s, and HTML4 still, more than ten years later, hasn’t reached the level that we want to reach with HTML5.” - WHATWG (source)

Heavens to Mergatroid. 2022. Or later? Holy crap. But it sounds like it’s coming it bits and pieces — and parts are already implemented in some browsers.

“We’re trying a new spec design model with HTML 5, where certain parts of the spec can be considered “done” before others. This is because we have parts of the spec that are very mature, with multiple implementations, test suites, and active use, and we have others that are very new, and very much in flux.” - Ian Hickman (source)

At any rate, HTML 5 will slowly creep along. Maybe it’ll become a full specification, maybe not. But hopefully HTML will continue to evolve and become more useful. For a field that changes so much and so rapidly, it’s amazing that’s we’re still stuck with such (relatively) ancient specs as the foundation of everything webby.