Journal tags: whatwg



Secret src

There’s been quite a brouhaha over the past couple of days around the subject of standardising responsive images. There are two different matters here: the process and the technical details. I’d like to address both of them.

Ill communication

First of all, there’s a number of very smart developers who feel that they’ve been sidelined by the WHATWG. Tim has put together a timeline of what happened:

  1. Developers got involved in trying to standardize a solution to a common and important problem.
  2. The WHATWG told them to move the discussion to a community group.
  3. The discussion was moved (back in February), a general consenus (not unanimous, but a majority) was reached about the picture element.
  4. Another (partial) solution was proposed directly on the WHATWG list by an Apple employee.
  5. A discussion ensued regarding the two methods, where they overlapped, and how the general opinions of each. The majority of developers favored the picture element and the majority of implementors favored the srcset attribute.
  6. While the discussion was still taking place, and only 5 days after it was originally proposed, the srcset attribute (but not the picture element) was added to the draft.

A few points in that timeline have since been clarified. That second step—“The WHATWG told them to move the discussion to a community group”—turns out to be untrue. Some random person on the WHATWG mailing list (which is open to everyone) suggested forming a Community Group at the W3C. Alas, nobody else on the WHATWG mailing list corrected that suggestion.

Then there’s apparent causality between step 4 and 6. Initially, I also assumed that this was what happened: that Tess had proposed the srcset solution without even being aware of the picture solution that the Community Group had independently come up with it. It turns out that’s not the case. Tess had another email about the picture proposal but she never ended up sending it. In fact, her email about srcset had been sitting in draft for quite a while and she only sent it out when she saw that Hixie was finally collating feedback on responsive images.

So from the outside it looked like there was preferential treatment being given to Tess’s proposal because it came from within the WHATWG. That’s not the case, but it must be said: the fact that srcset was so quickly added to the spec (albeit in a different form) doesn’t look good. It’s easy to understand why the smart folks in the Responsive Images Community Group felt miffed.

But let’s be clear: this is exactly how the WHATWG is supposed to work. Use-cases are evaluated and whatever Hixie thinks is best solution gets put in the spec, regardless of how popular or unpopular it is.

Now, if that sounds abhorrent to you, I completely understand. A dictatorship should cause us to recoil.

That’s where the W3C come in. Their model is completely different. Everything is done by committee there.

Steve Faulkner chimed in on Tim’s post with his take on the two groups:

It seems like the development of HTML has turned full circle, the WHATWG was formed to overthrow the hegemony of the W3C, now the W3C acts as a counter to the hegemony of the WHATWG.

I think he’s right. The W3C keeps the rapid, sometimes anarchic approach of the WHATWG in check. But the opposite is also true. Without the impetus provided by the WHATWG, I’m not sure that the W3C HTML Working Group would ever get anything done. There’s a balance that actually works quite well in practice.

Back to the situation with responsive images…

Unfortunately, it appears to people within the Responsive Images Community Group that all their effort was wasted because their proposed solution was summarily rejected. In actuality all the use-cases they gathered were immensely valuable. But it’s certainly true that the WHATWG didn’t make it clearer how and where developers could best contribute.

Community Groups are a W3C creation. They don’t have anything to do with the WHATWG, who do all their work on their own mailing list, their own wiki and their own IRC channel.

I do think that the W3C Community Groups offer a good place to go bike-shedding on problems. That’s a term that’s usually used derisively but sometimes it’s good to have a good ol’ bike-shedding without clogging up the mailing list for everyone. But it needs to be clear that there’s a big difference between a Community Group and a Working Group.

I wish the WHATWG had done a better job of communicating to newcomers how best to contribute. It would have avoided a lot of the frustrations articulated by Wilto:

Unfortunately, we were laboring under the impression that Community Groups shared a deeper inherent connection with the standards bodies than it actually does.

But in any case, as Doctor Bruce writes at least now there’s a proposed solution for responsive images in HTML: The Living Standard:

I don’t really care which syntax makes the spec, as long as it addresses the majority of use cases and it is usable by authors. I’m just glad we’re discussing the adaptive image problem at all.

So let’s take a look at the technical details.

src code

The Responsive Images Community Group came up with a proposal based off the idea of minting a new element, called say picture, that mimics the behaviour of video

<picture alt="image description">
  <source src="/path/to/image.png" media="(min-width: 600px)">
  <source src="/path/to/otherimage.png" media="(min-width: 800px)">
  <img src="/path/to/image.png" alt="image description">

One of the reasons why a new element was chosen rather than extending the existing img element was due to a misunderstanding. The WHATWG had explained that the parsing of img couldn’t be easily altered. That means that img must remain a self-closing element—any solution that requires a closing /img tag wouldn’t work. Alas, that was taken to mean that extending the img element in any way was off the cards.

The picture proposal has a number of things going for it. Its syntax is easily understandable for authors: if you know media queries, then you know how to use picture. It also has a good fallback for older browsers : a regular img element. This fallback mechanism (and the idea of multiple source elements with media queries) is exactly how the video element is specced.

Unfortunately using media queries on the sources of videos has proven to be very tricky for implementors, so they don’t want to see that pattern repeated.

Another issue with multiple source elements is that parsers must wait until the closing /picture tag before they can even begin to evaluate which image to show. That’s not good for performance.

So the alternate solution, based on Ted’s proposal, extends the img element using a new srcset attribute that takes a comma-separated list of values:

image description

Not nearly as pretty, I think you’ll agree. But it is actually nice and compact for the “retina display” use-case:

image description

Just to be clear, that does not mean that otherimage.png is twice the size of image.png (though it could be). What you’re actually declaring is “Use image.png unless the device supports double-pixel density, in which case, use otherimage.png.”

Likewise, when I declare:

srcset="/path/to/image.png 600w 400h"

…it does not mean that image.png is 600 pixels wide by 400 pixels tall. Instead, it means that an action should be taken if the viewport matches those dimensions.

It took me a while to wrap my head around that distinction: I’m used to attributes describing the element they’re attached to, not the viewport.

Now for the really tricky bit: what do those numbers—600w and 400h—mean? Currently the spec is giving conflicting information.

Each image that’s listed in the srcset comma-separated list can have up to three values associated with it: w, h, and x. The x is pretty clear: that’s the pixel density of the device. The w and h values refer to the width and height of the viewport …but it’s not clear if they mean min-width/height or max-width/height.

If I’m taking a “Mobile First” approach to development, then srcset will meet my needs if w and h refer to min-width and min-height.

In this example, I’ll just use w to keep things simple:

(Expected behaviour: use small.png unless the viewport is wider than 600 pixels, in which case use medium.png unless the viewport is wider than 800 pixels, in which case use large.png).

If, on the other hand, w and h refer to max-width and max-height, I have to take a “Desktop First” approach:

(Expected behaviour: use large.png unless the viewport is narrower than 800 pixels, in which case use medium.png unless the viewport is narrower than 600 pixels, in which case use small.png).

One of the advantages of media queries is that, because they support both min- and max- width, they can be used in either use-case: “Mobile First” or “Desktop First”.

Because the srcset syntax will support either min- or max- width (but not both), it will therefore favour one case at the expense of the either.

Both use-cases are valid. Personally, I happen to use the “Mobile First” approach, but that doesn’t mean that other developers shouldn’t be able to take a “Desktop First” approach if they want. By the same logic, I don’t much like the idea of srcset forcing me to take a “Desktop First” approach.

My only alternative, if I want to take a “Mobile First” approach, is to duplicate image paths and declare ludicrous breakpoints:

I hope that this part of the spec offers a way out:

for the purposes of this requirement, omitted width descriptors and height descriptors are considered to have the value “Infinity”

I think that means I should be able to write this:

It’s all quite confusing and srcset doesn’t have anything approaching the extensibility of media queries, but I hope we can get it to work somehow.

Three questions

Craig Grannell from .Net magazine got in touch to ask me a few short questions about last week’s events around HTML5. I thought I’d share my answers here rather than wait for the tortuously long print release cycle.

What are your thoughts on the logo?

The logo is nice. Looks pretty sharp to me.

Why were you unhappy with W3C’s original stance (“general purpose visual identity”)? What do you think now they’ve changed this?

I was unhappy with the W3C’s original definition of HTML5 in the logo’s accompanying FAQ, where they lumped CSS, SVG and WOFF under the “HTML5” banner. I’m happy they changed that.

What’s your thinking on the current state of the HTML5 situation, given that WHATWG is dropping the 5 and just going with HTML?

I think the current situation makes things much clearer. The WHATWG are working on a continuous, iterative document called simply HTML. The W3C use that as a starting pointing for nailing down an official specification which will be the fifth official iteration of the HTML language called, sensibly enough, HTML5.

The WHATWG spec is the place to look for what’s new and evolving. The W3C spec, once it goes into Last Call, is the place to look for the official milestone that is HTML5. In practice, the two specs will be pretty much identical for quite a while yet.

But the truth is that authors shouldn’t be looking at specs to decide what to use—look at what browsers support in order to decide if you should use a particular feature—look at the spec to understand how to use features of HTML5.

For authors, it probably makes more sense to talk about HTML rather than HTML5. Remember that most of HTML5 is the same as HTML 4.01, HTML 3.2, etc. Answering yourself a question like “When can I use HTML5?” is a lot easier to answer if you rephrase it as “When can I use HTML?”

Most of the time, it makes a lot more sense to talk about specific features rather than referring to an entire specification. For example, asking “Does this browser support HTML5?” is fairly pointless, but asking “Does this browser support canvas?” is much more sensible.


Two good things have happened.


Firstly, as I hoped, the WHATWG have updated the name of their work to simply be HTML. This is something they tried to do a year ago, and I kicked up a stink. I was wrong. Having a version number attached to an always-evolving standard just doesn’t make sense. As Hixie put it:

…the technology is not versioned and instead we just have a living document that defines the technology as it evolves.

This change means that the whole confusing 2022 business that was misunderstood by so many people is now history:

Now that we’ve moved to a more incremental model without macro-level milestones, the 2022 date is no longer relevant.

The spec is currently labeled as a “Living Standard”. Personally, I find the “Living Standard” strapline a bit cheesy. I’d much rather the document title was simply “HTML” followed by the date of the last update.

Note that this change only applies to the WHATWG. The W3C will continue to pursue the “snapshot” model of development so the spec there definitely retains the number 5 and will follow the usual path of Working Draft, Last Call, Proposed Recommendation, and so on.

I think this difference makes it clearer what each group is doing. It was a pretty confusing situation to have two groups working on two specs, both called HTML5. Now it’s clear that the WHATWG is working more like how browsers do: constantly evolving and implementing features rather than entire specifications. Meanwhile the W3C are working on having a development milestone of those features set in stone and labelled as the fifth revision to the HTML language …and I think that is also an important and worthy goal.


The second piece of good news is that the W3C have backtracked on their “embrace and extend” attitude towards buzzwordism. When they launched the new HTML5 logo a few days ago, the W3C Communications Team initially said that HTML5 included CSS, SVG and WOFF‽ As Tantek said:

Fire the W3C Communications person that led this new messaging around HTML5 because it is one of the worst messages (if not the worst) about a technology to ever come out of W3C.

Following the unsurprising outbreak of confusion and disappointment that this falsehood caused, the W3C have now backtracked. HTML5 means HTML5. The updated FAQ makes it very clear that CSS3 is not part of HTML5.


I really wasn’t looking forward to starting every HTML5 workshop, presentation or article with the words, “Despite what the W3C says, HTML5 is not a meaningless buzzword…” Now I can safely say that the term “HTML5” refers to a technical specification, published at the W3C, called HTML5. Also, I can use that nice logo with a clear conscience.

Over time though, I’ll probably follow the WHATWG’s lead and simply talk about “what’s new in HTML.” As Remy points out, there are pedagogical advantages to untethering version numbers:

I don’t have to answer “Is HTML ready to be used?” ‘cos that’s a really daft question!

Bye, bye 5

One year ago, I objected strenuously when the WHAT WG temporarily changed the name of their spec from “HTML5” to plain ol’ “HTML”:

Accurate as that designation may be, I became very concerned about the potential confusion it would cause.

I understand why the WHATWG need to transition from using the term HTML5 to simply using the term HTML to describe their all-encompassing ongoing work, but flipping that switch too soon could cause a lot pain and confusion.

Now that term the “HTML5” has become completely meaningless—even according to the WC3—I think it’s time to rip off the bandaid and flip that switch.

I was wrong. Hixie was right. The spec should be called HTML.

If you need an all-encompassing term for every front-end technology under the sun, go ahead and use the term “HTML5.” Although personally, I quite like “the Web.”

Update: The WHATWG have duly updated the name of the spec.

HTML5 business as usual

It’s been a strange week in HTML5. The web—and Twitter in particular—has been awash with wailing and gnashing of teeth as various people weigh in with their opinions on either the W3C or the WHATWG—depending on which camp they’re in—being irreversibly broken …exactly the kind of ludicrous over-reaction at which the internet excels.

This particular round of chicken-littling was caused by the shuffling of some spec components. The W3C HTML Working Group recently decided to split microdata into a separate specification (which I think is fair enough given RDFa’s similar status). Hixie then removed some other parts of HTML5; a move which was seen as a somewhat petulant reaction to the microdata splittage. Cue outfreakage. Before too long, most of the changes were rolled back.

So all of the shouting and arguing was more about politics and procedure than about features or semantics. That’s par for the course when it comes to the HTML Working Group at the W3C; the technical discussions are outweighed by the political and procedural wranglings. But that’s the nature of the beast. Hammering out a standard is hard. Building consensus is really hard. The chairs of the working group face an uphill struggle every single day. Still, that’s a far cry from declaring the whole thing a waste of time.

As Tantek points out, if the HTML5 shenanigans seem particularly crazy, that’s only because they are that much more public than most other processes:

The previous several revisions of HTML (including XHTML) were largely developed in W3C Members-Only mailing lists (and face-to-face meetings) which contained a lot of similar “corporate politics, egotism, squabbles and petty disagreements” - however such tussles were invisible to search engines, the general public, and of course all the professional web developers and designers (like yourself) - you never saw how the sausage was made as it were.

Tantek was responding to a post by Malarkey who advises us to keep calm and carry on. That’s sensible advice, although he gets some push-back in the comments from people concerned about a market-led approach to web standards, wherein we only care about what browsers are implementing, not what’s enshrined into a standard.

It’s easy to polarise this issue into a black and white dichotomy: implementation first vs. specifications first. The truth, as always, is much more nuanced than that, as beautifully summed up by Rob O’Callahan:

Implementations and specifications have to do a delicate dance together. You don’t want implementations to happen before the specification is finished, because people start depending on the details of implementations and that constrains the specification. However, you also don’t want the specification to be finished before there are implementations and author experience with those implementations, because you need the feedback. There is unavoidable tension here, but we just have to muddle on through … I think we’re doing OK.

I think we’re doing OK too.

Not that I’m not immune to HTML5-related temper loss. Most recently, I was miffed with the WHATWG rather than the W3C but once again, it was entirely to do with specification organisation rather than specification contents.

The WHATWG have never been comfortable with the term HTML5 to describe the work they’re doing, which began life as Web Apps 1.0. The very idea of version numbers is anathema to their philosophy so they’re quite happy for the W3C to own the term HTML5 to describe a particular set-in-stone markup spec. But they still need a word to describe the monolithic ongoing WHATWG spec.

Historically, the term HTML5 was a pretty good fit for the WHATWG spec and it corresponded exactly with the W3C spec (in fact, the W3C spec is generated from the WHATWG spec). But Hixie declared Last Call for the WHATWG HTML5 spec a while back. That means that the specification at the WHATWG and the specification at the W3C can now diverge—the WHATWG spec contains everything in HTML5 and then some. To continue to label this WHATWG spec as simply HTML5 would be misleading. So a few weeks ago, the name of the spec changed from HTML5 to WHATWG HTML (including HTML5).

Accurate as that designation may be, I became very concerned about the potential confusion it would cause. Any front-end developer reading a document titled WHATWG HTML (including HTML5) might reasonably ask Oh, which bits are HTML5? …a question to which there’s no easy answer because at the WHATWG, the term HTML5 is seen as little more than a buzzword. In that sense, they share PPK’s assertion that HTML5 means whatever you want it to mean.

I was particularly concerned that the short URL would redirect to a document that wasn’t called HTML5. I could point developers at this diagram but I’m not sure that it would make things any clearer.

Things got fairly heated in the IRC channel as I argued for either a different redirect or a better document title. I understand why the WHATWG need to transition from using the term HTML5 to simply using the term HTML to describe their all-encompassing ongoing work, but flipping that switch too soon could cause a lot pain and confusion. A gradual evolution of titles reflecting the evolution of the contents seems better to me:

  1. HTML5
  2. HTML5 (including next generation additions still in development)
  3. WHATWG HTML (including HTML5)

Hixie made the change. The title of the WHATWG specification is currently at step 2. I think this will make things a lot clearer for authors.

  • Anyone looking for the specification that will become a W3C candidate recommendation called HTML5 should look at the W3C site:
  • Anyone looking for the ongoing evolving specification that HTML5 is a part of should look at the WHATWG site:

I’m happy that this has been cleared up and yet I hope that smart, savvy front-end developers who have read this far will think that I’ve just wasted their time. That would be a healthy reaction to reading a bunch of irrelevant guff about what specifications are called and how they are organised. Your time would be far better spent implementing the specifications and providing feedback.

That’s certainly a far better use of your time than simply shouting FAIL!

Update: And, right on cue, Mark Pilgrim updates the WHATWG blog to explain the spec name change.

HTML5 watch

Keeping up with HTML5 can seem like a full-time job if you’re subscribed to both the W3C public-html list and the WHATWG mailing list.

If you have to choose just one, the WHATWG list is definitely the red pill. The W3C list has a very high volume of traffic, mostly about politics and procedure. Sam Ruby deserves a medal for keeping the whole thing on an even keel.

The WHATWG list, on the other hand, can get pretty nitty-gritty in its discussions of Web Workers, Offline Storage and other technologies that are completely over my head.

The specification itself is shaping up nicely. My list of bugbears is getting shorter and shorter:

  1. I’m still not convinced that the article element is necessary, given that it is almost indistinguishable from section. Having two very similar elements is potentially very confusing for authors. It’s hard enough deciding the difference between a section and a div.
  2. The time element is still unnecessarily restrictive. I don’t just mean that it’s restrictive in the sense that you can’t mark up a month, the very definition is too narrow. I hoisted the HTML5 spec by its own petard recently, pointing out that a different portion of the spec violates the definition of time.
  3. The cite element is also too restrictively defined, and in a backwards-incompatible way to boot. I’ve written more about that over on 24 Ways.

There are much bigger issues than these still outstanding—mostly related to the accessibility of audio, video and canvas—but I’ll leave it to smarter people than me to tackle those. My issues all revolve around semantics and, let’s face it, they’re kind of piddling little problems in the grand scheme of things.

On the whole, I’d say the spec is looking mighty fine. Most of it is ready for use today.

I think the next big challenge for HTML5 lies with the tools. It’s great that we’ve got a validator but what we really need is —something like JSlint but for checking markup writing style: case sensitivity of tags, quotes around attributes, that kind of thing. Robert Nyman concurs.

Let be clear: I’m not talking about a validator that checks for polyglot documents i.e. HTML that can also be parsed as XML. I’m talking purely about writing style and personal preference; a tool that will help enforce an in-house style guide of arbitrary “best” practices.

I’ve impressed this upon Henri in IRC on a few occasions. He has explained to me that it’s not so easy to build a true syntax checker …and no, you can’t just use regular expressions.

Still, I think that there would be enormous value in having even an imperfect tool to help authors who want to write HTML5 right now but also want to enforce a strict syntax on themselves. A working rough’n’ready lint tool that catches 80% of the most common gotchas is better than a theoretical perfect tool that will work 100% of the time but that currently works 0% of the time because it doesn’t exist yet.

Anybody want to step up to challenge?

The devil in the details

Looking through the list of hiccups highlighted by the HTML5 Super Friends and my own personal tally, things are progressing at a nice clip with HTML5.

That still leaves a few issues:

  • The confusion between section and article that I’ve been researching.
  • The restrictive content model of the small element not matching that element’s updated semantics.
  • The time element not allowing month or year dates i.e. YYYY-MM or YYYY.

Then there’s the issue with details and figure. The insistence on recycling the legend element leads to all sorts of problems with browsers today, as described by Remy.

This has been an ongoing discussion in the HTML5 IRC channel and on the HTML5 mailing lists. It flared up again recently and I fired off an email to the HTML Working Group yesterday:

I understand the aversion to introducing a new element … but I don’t understand why legend is being treated as the only possible existing element to recycle.

For example, dt and dd are being recycled in the new context of dialog so they no longer mean “definition title” and “definition description”. Now they can also mean (presumably) “dialog title” and “dialog description”.

If those elements are already being recycled, why not apply the same thinking to details so that dt and dd could also mean “details title” and “details description”?

To be honest, I was just spouting that out without really thinking. How about… something like—not this, obviously, not this, but what if…

Ok… Not This…

So imagine my surprise when Hixie responded:

That’s not a bad idea actually. Ok, done.

Wow. Okay.

While I was at it, I also did this for figure

Alright. Makes sense, I suppose …although the names of the elements dt and dd aren’t quite as intuitive in the context of figure as they are in details.

and removed dialog from the spec altogether.

Er …okay. Seems somewhat unrelated to the issue at hand but I guess that the dialog element has been a point of contention. It’s mentioned by the HTML5 Super Friends so that’s another one that we can tick off the list.

So how should we mark up conversations now? Here’s what the spec now suggests:

Authors who need to mark the speaker for styling purposes are encouraged to use span or b.

Um… what? The b element? Really? You have got to be kidding.

Excuse me while I channel Carrie’s mother, but I can predict exactly how authors are going to react to this advice: They’re all going to laugh at you!

@gcarothers: Jaw, floor, WHAT?! Why in the world would #html5 suggest using <b> tags to markup names?

@akamike: There are more appropriate tags than <b> for marking up names in conversations. “The b element should be used as a last resort…” #html5

@cssquirrel: Well, if the <p><b> recommendations for dialog in #html5 persist for a week, I know what I’m drawing.

Perhaps now would be a good time to mention that the cite element is also listed by the HTML5 Super Friends. Call me crazy but I think it might just be the right element for marking up the person being cited.

<p> <cite>Costello</cite>: <q>Who's playing first?</q> </p>
<p> <cite>Abbott</cite>: <q>That's right.</q> </p>

Testing HTML5

dConstruct week is in full swing. The conference itself is tomorrow. Remy and Brian are doing their workshops today. Myself, Rich and Nat did our HTML5 and CSS3 Wizardry workshop yesterday.

I was handling the HTML5 side of things and had quite a bit of fun with it. I put together an HTML5 pocket book using using Natalie’s superb CSS. View it in a Webkit or Gecko-based browser and then print it out to experience the CSS3 transform magic. Natalie made a CSS3 pocket book for the workshop which was a nice self-documenting example of CSS transforms. Hers turned out much neater than mine—my folding fu isn’t so good. But hey, it’s the thought that counts and I figured it was nice to give every attendee something hand-crafted.

I prepared some exercises for the workshop and I have to admit that I had an ulterior motive with one of them. Each attendee was provided with two sheets of paper. One sheet of paper listed some new elements in HTML5 in alphabetical order:

  1. article
  2. aside
  3. details
  4. figure
  5. footer
  6. header
  7. hgroup
  8. nav
  9. section

On another sheet of paper, I listed definitions of those elements taken from the spec but in no particular order:

  • …a group of introductory or navigational aids.

  • …represents a section of a page that consists of content that is tangentially related to the content around it, and which could be considered separate from that content.

  • …used to group a set of h1–h6 elements when the heading has multiple levels, such as subheadings, alternative titles, or taglines.

  • …typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like.

  • …some flow content, optionally with a caption, that is self-contained and is typically referenced as a single unit from the main flow of the document.

  • …a section of a page that links to other pages or to parts within the page: a section with navigation links.

  • …a thematic grouping of content, typically with a heading, possibly with a footer.

  • …a section of a page that consists of a composition that forms an independent part of a document, page, or site.

  • …additional information or controls which the user can obtain on demand.

I then asked the attendees to match up the definitions with the element whose name sounded like the best match. To be clear: this wasn’t a test of knowledge. I was testing the spec.

Giving this exercise to thirty very savvy web developers yielded some clear results. There’s definitely a lot of confusion around when to use section and when to use article. I’m not convinced that there needs to be two different elements, especially now that the article element no longer takes the cite or pubdate attributes. figure and aside were also an area of confusion.

When the workshop was over, I collected the pages with everyone’s answers. Once I get some time I’ll publish the results, probably in a spreadsheet. Then I can present that data to the WHATWG list. Some people on IRC were wondering why my superfriends and I haven’t presented our concerns by email. Well, we will. But I think there’s a lot of value in publicly discussing this stuff (and soliciting feedback). Mostly though, I’ll feel a lot more comfortable about raising an issue if I can back it up with some data. There’s a big difference between telling Hixie your opinion and giving Hixie data.

So, in a very real sense, I got a lot of the workshop. It took quite a while to put the workshop together. The face-to-face meeting with my unicorn-powered peers in New York proved to be absolutely invaluable. I was tweaking the slides right up till the day of the workshop; not because I was rearranging the content, but because the spec was literally changing overnight (albeit in small ways).

Now that the workshop is over, I can relax. And relax I will …in Canada. I’m off to Whistler this weekend for Jessica’s brother’s wedding, followed by a couple of days in Vancouver.

Alas, that means I won’t be around for all of dConstruct. I’ll be able to catch Adam Greenfield followed by Mike Migurski with Ben Cerveny before heading up to Heathrow. But I won’t be able to make it to BarCamp.

Well, I’m sure that everyone who’s coming to Brighton will have plenty of fun without me. And I plan to have plenty of fun in British Columbia …though at some stage, I need to make some time to collate all that yummy data from the workshop.

HTML5 and me

I can never pinpoint the exact moment at which I “get into” a particular technology. CSS, DOM Scripting, microformats …there was never any Damascene conversion to any of them. Instead, I’d just notice one day, after gradually using the technology more and more, that I was immersed in it.

That’s how I feel about now.

There’s another feeling that accompanies this realisation. I remember feeling it about CSS in the late 90s and about DOM Scripting half a decade ago. At the same time as I look up from my immersion, I cast a glance around the web development landscape and ask Why aren’t more people paying attention to this?

In the case of HTML5, this puzzling state of affairs can, to a large extent, be explained by the toxic 2022 meme. Working web developers with an idle interest in HTML5 would google the term, find a blog post telling that it won’t be “ready” until 2022, and then happily return to their work, comforted by the knowledge that HTML5 was some distant dream on the horizon—one that doesn’t affect them in any way today.

Nothing could be further from the truth. The Last Call Working Draft status is (optimistically) planned for October; that’s one month away.

And what rough beast, its hour come round at last, slouches towards Bethlehem to be born?

If you want to have a say in the formation of the most important web standard in existence, don’t put off getting involved. As Bruce says, If you don’t vote, you can’t bitch.

Still, I think the attitude of most web developers towards HTML5 right now is, at the very least, “interested, if a little sceptical”—that’s certainly how I felt when I started dabbling in it.

A little while back, I got together with some of my interested (if a a little sceptical) colleagues in New York, thanks to a generous invitation from Zeldman.

Dan Cederholm, Jeremy Keith, Eric Meyer, Ethan Marcotte, Tantek Çelik, Nicole Sullivan, Wendy Chisholm

After a fairly intense two days of poring over the spec, I think it’s fair to say that, on balance, the interest increased and the scepticism decreased. That’s not to say that everything looks rosy in the current incarnation of HTML5. When you’ve got some of the smartest front-end web developers I know of in the same room together and they all agree that some parts of the spec are confusing or downright wrong, that’s quite worrying.

On the plus side, most of the issues are pretty minor in the grand scheme of things. It’s fair to say that most of the stuff that interests web authors—the semantic side of things—only accounts for a small part of HTML5. Most of the HTML5 specification is about error handling, APIs and shiny new interactive content. There are plenty of programmers and browser makers forging those powerful new tools. But as qualified as they are to hammer out those complex constructs, they are not necessarily the most qualified to make decisions on creating new structural elements. For that, you need the input of authors. And authors have been decidedly slow to get involved with HTML5.

It’s time for authors to get involved. I believe our voices will be welcomed. According to the HTML design principles:

…consider users over authors over implementors over specifiers over theoretical purity.

I’ll get the ball rolling with my own little list of things that are troubling me…


I’m with Bruce and Remy. If the small element is being redefined for disclaimers, caveats, legal restrictions, or copyrights, it needs to be handling how that kind of content is published in the wild. That means it needs to be able to wrap paragraphs, lists and other flow content.

Alternatively, it should go the way of its evil twin, the big element, and simply be deprecated …sorry, I mean obsolete and non-conforming.


I’ll join in the chorus of people who think that the restrictions on the information that the new time element can contain are unnecessarily draconian. You can encode a date and time, you can encode a date, but you can’t encode just a month and a year. So you can’t make a piece of information like “April 1912” machine-readable. The spec says the time element:

…is intended as a way to encode modern dates and times in a machine-readable way

Which is great. But the sentence doesn’t finish there. It goes on:

so that user agents can offer to add them to the user’s calendar.

That’s one use case! I don’t think it’s wise to rain on the parade of anyone wanting to build, say, timeline mashups. Trying to mandate use cases ahead of time is not just counter-productive, it’s probably impossible. Can you imagine if Flickr had launched their API with strict instructions that it could only be used for one particular purpose?


I have nothing against the figure element itself, although it does seem uncomfortably close to aside, but the insistence on recycling the legend element to handle the caption is problematic.

Don’t get me wrong: I’m all for re-using existing elements rather then creating new ones, and I know that Hixie looked at all the options. But the way that browsers currently treat the legend element makes it unusable outside of a form.

I think that the label element could work instead.


Just like figure, the details element reuses legend. In this case, label won’t do the trick. details is an interactive element and it doesn’t look like the label element can be made keyboard accessible.

In this case, as undesirable as it is, a new element may be called for.


I’ve got two issues with the article element.

  1. Firstly, its definition sounds awfully similar to section. I’m not convinced that there needs to be two different elements. Having two elements that look like a duck, walk like a duck and quack like a duck is just going to lead to confusion amongst authors wondering which duck to use.

  2. The article element, unlike the section element can take an optional pubdate attribute to encode the publication date. I’m all in favour of having this information be machine-readable but the pubdate attribute smells like dark data, subject to metacrap rottage. In most cases, the publication date will be repeated in the content of the article anyway, so I’m in favour of adding a flag there rather than duplicating data. A Boolean pubdate attribute on a time element within an article header or footer should do the trick.

    Update: Belay that last gripe, ensign. As proof of just how fast this spec moves, less than 24 hours after I published this, Hixie has implemented what I was suggesting.

Speaking of footer, this one is the biggie…


There is a big disconnect between what the HTML5 spec calls a footer and what authors on the web call a footer.

According to the spec, you’re only supposed to put some kinds of content inside a footer:

Flow content, but with no heading content descendants, no sectioning content descendants, and no header or footer element descendants.

That means no nav or headings in footer. The way that the footer element is defined in the spec, it’s a slightly more expanded version of address.

Ah, address! One of the most problematic elements in HTML 4. It is often incorrectly used to mark up street addresses. But is it any wonder? When an element has a name address, it’s hardly surprising that authors are going to use it for marking up addresses. The same thing is going to happen with footer.

The term “footer” was not invented for HTML5. It’s been in use on the web for years and in print for even longer. But if you ask any author to define what they mean by the term “footer”, you’ll get a very different definition to the one in the HTML5 spec. They may even point to specific examples of footers on sites like Flickr or on blogs, where they contain headings and navigation.

To be fair, when the new structural elements were being forged back in 2005, there wasn’t as much prevalence of what Derek Powazek termed fat footers. So when Hixie ran his analytics on a shitload of web pages crawled by Google and found that “footer” was by far the most common class name, most footer content was pretty meagre. But usage changes (see also: time).

The way that the element named footer is defined in HTML5—to be used multiple times in a single document in sections and articles as well as at the document level—is very different from the convention named footer in common usage on the web today. Most of the instances of what authors call a footer are more like what the HTML5 spec defines as aside.

I don’t want to spend the next decade telling authors not to mark up their footers as footers. It was bad enough telling people not to mark up addresses as addresses. In any case, authors aren’t going to listen. If they see there’s an element called footer, they will assume it refers to the device known as a footer, and mark up their content accordingly. At that point, the HTML5 spec will have become a work of fiction instead of documenting what’s actually on the web.

One of two things needs to happen. Either:

  1. The content model of footer is updated to match that of header, which is much more liberal in what it accepts, or:
  2. The name of the element currently called footer should be changed to match the current, restrictive definition. I suggest using contentinfo, which is the name of an existing ARIA role for exactly this kind of content.

ARIA roles, by the way, are an excellent addition to HTML5. ARIA integration is a win for ARIA and a win for HTML5, in my opinion. Most of all, it’s a win for authors who now have a whole swathe of extra semantics they can sprinkle into their documents (and use as styling hooks with attribute selectors).

Thus endeth my list of things I want to see fixed in HTML5. I’m leaving out the massive issue of canvas accessibility because:

  1. that’s beyond my area of expertise,
  2. smarter people than me are working on it, and
  3. I think that canvas would probably benefit from being spun off into a separate spec.

There are other little things that bother me in HTML5—hgroup smells funny, cite shouldn’t be restricted to titles of works, and I miss the rev attribute on links—but those are all personal foibles; opinions unsupported by data. I’d rather concede than argue without data.

Because, make no mistake, data is what’s needed if you want to affect change in HTML5. Despite the attempts to paint Hixie as a stubborn, opinionated dictator, he is himself a slave to data. He shows an almost robot-like ability to remove his own ego from a debate and follow where the data leads.

If you are an author of HTML documents, I strongly encourage you to get involved in the HTML5 process.

  1. Read the spec.
  2. Join the mailing list.
  3. Hang out in the IRC channel.

Like I said, most of the spec and discussion is about APIs rather than semantics, but it’s precisely because the spec isn’t directly aimed at authors that authors need to get involved.

The HTML5 Equilibrium

is a strange character with what appears to be a split personality. Hardly surprising then that something so divided would appear to be so divisive.

First of all, there’s the spec itself.

The specification

HTML5 walks a fine line between maintaining backward compatibility with existing markup and forging the way as a modern, updated specification for the future. If it strays too far in paving the cowpaths and simply codifies what authors already publish, then the spec would mandate using tables for layout and font elements for presentation because that’s still what most of the web does. On the other hand, if it drifts too far in the other direction, the result will be something as theoretically pure but as practically useless as .

The result is that HTML5 appears to be a self-contradictory mess. But it’s hard to imagine a successful web technology that isn’t a mess. That’s because the web itself is a mess. Clay Shirky described exactly how messy it is back in 1996:

The server would use neither a persistent connection nor a store-and-forward model, thus giving it all the worst features of both telnet and e-mail.

The hypertext model would ignore all serious theoretical work on hypertext to date. In particular, all hypertext links would be one-directional, thus making it impossible to move or delete a piece of data without ensuring that some unknown number of pointers around the world would silently fail.

And yet the web succeeded because:

…of the various implementations of a worldwide hypertext protocol, we have the worst one possible.

Except, of course, for all the others.

…a reference to Churchill’s oft-cited maxim that:

…democracy is the worst form of government except all the others that have been tried.

Which brings us nicely to the subject of governance and process, another area where HTML5 appears to be split.

The process

Democracy—or at least, consensus—drives the process of most W3C specs. But HTML5 isn’t just being developed at the W3C. HTML5 is also being developed by the WHATWG. Sounds crazy, doesn’t it? The reasons for the split are historical—the W3C rejected HTML as the future of the web in 2004 so the WHATWG started their own work and then the WC3 had a change of heart in 2007. Hence the parallel development. It turns out to be a pretty good system of . The editors on the WHATWG side—Ian Hickson and —are balanced by the chairs on the W3C side—Chris Wilson and Sam Ruby.

The WHATWG process isn’t democratic. There’s no voting on issues. Instead, Hixie acts as a self-described benevolent dictator who decides what goes into and what comes out of the spec. That sounds, frankly, shocking. The idea of one person having so much power should make any right-thinking person recoil. But here’s the real kick in the teeth: it works.

In theory, a democratic process should be the best way to develop an open standard. In practice, it results in a tarpit (see XHTML2, CSS3, and pretty much any other spec in development at the W3C—not that the membership policy of the W3C is any great example of democracy in action).

In theory, an unelected autocrat having control of a specification is abhorrent. In practice, it works really, really well …if it’s the right person.

That’s always been the case with benevolent dictatorships. The populace transfers moral responsibility to the of the state, personified by an-powerful ruler like Shakespeare’s Henry V:

If his cause be wrong, our obedience to the King wipes the crime of it out of us.

That’s a lot of responsibility for one person to carry. Remarkably, Hixie carries the weight with exceptional disinterest and a machine-like even-handedness:

Let it be said that Ian Hickson is the Solomon of web standards; his summary of the situation is mind-bogglingly even-handed and fair-minded.

But it doesn’t always seem that way to those on the outside looking in at the HTML5 process. Debates around the summary attribute or RDFa might well give the impression that Hixie is ignoring voices in opposition. Nothing could be further from the truth. The real challenge is in finding good solutions to problems, and sometimes that doesn’t necessarily mean using an existing solution—despite the pave the cowpaths mantra.

If you have a potential solution to a problem in HTML5, the way to present it is with data. If you don’t have the data, then maybe it isn’t such a good solution. I’ve experienced this myself with the rev attribute, which has been removed from HTML5. I think it should remain. I think it’s a potentially powerful attribute. But I can’t argue with the data. My personal preference isn’t a good enough reason to keep it (‘though I may occasionally tip out some beer to honour its memory).

The irony is that HTML5 has the reputation of being a spec beyond the influence of the average web developer when in fact it has the most open process of any web standard. If you want to have a say in the development in CSS3… well, good luck with that. If you want to have a say in the development of HTML5, you can.

Unlike just about every other W3C activity, the HTML working group is open to the public. You can join in as a public invited expert—except you don’t actually get invited. Instead you’ll need to complete this three-step process:

  1. Sign up for an account with the W3C.
  2. Fill in the invited expert application—you’ll need your W3C credentials to do this.
  3. Fill in the form for joining the HTML working group.

But a lot of the activity on the W3C side of things is very much about the process of developing a spec; voting, consensus and meetings. To have your say in putting the content of the HTML5 spec together, join in the WHATWG activities.

Two words of warning…

Firstly, time is of the essence. HTML5 is due to enter Last Call Working Draft in October of this year. From then it’s going to be a race towards Candidate Recommendation in 2012. If you want to influence this spec, now is the time to get involved. Don’t wait. The FUD around the boogieman date of 2022 is proving to be a particularly virulent meme that web developers have latched on to as an excuse for not caring about HTML5.

Secondly, you might be surprised by the contents of the specification. This is yet another area where HTML5 displays a split personality.

The feature set

Traditionally, HTML has been a format for semantically marking up hypertext—the clue is in the name. That’s still true but HTML5 is also a format for creating web applications; the WHATWG work that became HTML5 started life as a spec for web apps. This means that a lot of the discussions on the mailing list are about APIs, DOM trees, and some fairly code-heavy stuff around canvas and video. Discussions of the semantics of new structural elements like header, footer and article aren’t nearly as prevalent—all the more reason for working web developers to get involved in the process.

The truth is that much of the HTML5 spec isn’t aimed at web developers at all; it’s aimed at browser makers. This has fostered some conspiracy theories about how browser makers are controlling the spec but the truth is that browser makers have always had the final say in what gets implemented. It doesn’t matter how perfect a web standard is if nobody can use it. Hixie, for all his apparent power, acknowledges this:

I don’t want to be writing fiction, I want to be writing a spec that documents the actual behaviour of browsers.

Fortunately we don’t have to wade through a spec aimed at browser makers. Michael Smith has taken all the author-specific parts of HTML5 and published them in a parallel document: HTML5: The Markup Language.

Sam Ruby tells of a useful distinction drawn up by TV Ramen of the kind of new features we’re seeing in HTML5:

extending the platform vs. extending the language.

The first type of feature is something that requires significant effort from browser makers; canvas, video, and all the new APIs. The second type of feature is something that requires very little effort from browser makers but is enormously significant for authors; header, footer, article, etc.

The diagnosis

HTML5 is the web equivalent of a circus tightrope act, performing equal feats of balancing and juggling

  • backward compatibility with shiny new features,
  • W3C consensus with WHATWG benevolent dictatorship,
  • and new browser features with new semantics.

It’s hardly surprising that such a schizophrenic spec can seem so confusing. If you spend some time immersing yourself in the world of HTML5, most of this confusion will evaporate. If symptoms persist, I recommend consulting the HTML5 doctor.

Parroting Pareto

One of the principles underlying the design and development of microformats is to adapt to current behaviors and usage patterns. This ensures that microformats are built upon data that people are already publishing. It’s a lot easier to get people to format existing data than it is to change what they publish entirely. That ties in with another principle: ease of authoring is important.

A lot of the watchwords of microformats dovetail nicely with , also known as the 80/20 rule. In the case of microformats this means aiming for low-hanging fruit and solving 80% of the problems with 20% of the effort.

The Pareto principle has proven to be a very good guide for microformats, especially when you consider :

  • infinitely extensible and open-ended
  • an attempt to get everyone to change their behavior and rewrite their tools
  • a whole new approach that throws away what already works today

The success of microformats can almost certainly be attributed to the Pareto-driven principles underlying their creation. That success—and the success of the community clustered around microformats—has prompted other movements to adopt similar working principles, WHATWG being the most visible exemplar.


I am more than a little concerned at the way that studying existing behaviour is being held up as a make-or-break point in discussions around HTML5. Unlike microformats, HTML does need to cover a lot of situations including some that fall far outside the 80%-90% curve.

Accessibility is the most obvious area of contention. By their very nature, accessibility concerns are not going to affect the majority of users. That doesn’t mean they can be dismissed. This is as true for microformats as it for HTML5. Technically, the could be dismissed simply by invoking the Pareto principle but that would clearly be an untenable position. Instead, the microformats community and the accessibility community have been working together towards possible alternatives (the first step being to document test cases—the have been working their asses off at that).

So accessibility is an area where the Pareto principle simply doesn’t hold up, in my opinion. That’s why I’m concerned by Mark Pilgrim’s dismissal of the longdesc attribute. It’s a well-reasoned dismissal founded almost entirely on existing behaviour: most people aren’t publishing images using longdesc, therefore it should be dropped. Similar research has been used to justify the non-requirement of the alt attribute and, God help us all, the reintroduction of the font element. It’s all very well-reasoned and logical. It’s also, in my opinion, wrong.

We know that most Web pages are crap— is a relative of the Pareto principle. If existing behaviour is given such importance in the development of HTML5, then the format will only end up codifying what most people are publishing: crap, in other words.

The longdesc situation is a classic case in point. Here’s an attribute that is actually supported in assistive technology; an unusual situation, given Freedom Scientific’s usual glacial pace. That’s not the problem. The problem is that not many people are implementing longdesc. The solution is either:

  1. educate publishers or
  2. provide an alternative and lobby screen-reader manufacturers to implement it—good luck with that.

I’m not having a go at Mark here and I don’t want to single him out at all. My concern lies with the over-reliance by the WHATWG on the Pareto principle in general and existing behaviour in particular. I think that justifications based on raw numbers are behind most of the concerns of the HTML 4 All group.

On an unrelated note… let me quickly point out another issue with the Pareto principle, unrelated to HTML. The 80/20 is misleading. Human minds are pattern recognition machines; as soon as we see the numbers 80 and 20, our brains jump to the conclusion that they are both fractions of the same total (100). In fact, they are percentages of different totals. The Pareto principle could just as easily be the 80/30 rule or the 90/20 rule.