Tags: html5



Conversational interfaces

Psst… Jeremy! Right now you’re getting notified every time something is posted to Slack. That’s great at first, but now that activity is increasing you’ll probably prefer dialing that down.

Slackbot, 2015

What’s happening?

Twitter, 2009

Why does everyone always look at me? I know I’m a chalkboard and that’s my job, I just wish people would ask before staring at me. Sometimes I don’t have anything to say.

Existentialist chalkboard, 2007

I’m Little MOO - the bit of software that will be managing your order with us. It will shortly be sent to Big MOO, our print machine who will print it for you in the next few days. I’ll let you know when it’s done and on it’s way to you.

Little MOO, 2006

It looks like you’re writing a letter.

Clippy, 1997

Your quest is to find the Warlock’s treasure, hidden deep within a dungeon populated with a multitude of terrifying monsters. You will need courage, determination and a fair amount of luck if you are to survive all the traps and battles, and reach your goal — the innermost chambers of the Warlock’s domain.

The Warlock Of Firetop Mountain, 1982

Welcome to Adventure!! Would you like instructions?

Colossal Cave, 1976

I am a lead pencil—the ordinary wooden pencil familiar to all boys and girls and adults who can read and write.

I, Pencil, 1958

Ælfred ordered me to be made

Ashmolean Museum, Oxford

The Ælfred Jewel, ~880

Technical note

I have marked up the protagonist of each conversation using the cite element. There is a long-running dispute over the use of this element. In HTML 4.01 it was perfectly fine to use cite to mark up a person being quoted. In the HTML Living Standard, usage has been narrowed:

The cite element represents the title of a work (e.g. a book, a paper, an essay, a poem, a score, a song, a script, a film, a TV show, a game, a sculpture, a painting, a theatre production, a play, an opera, a musical, an exhibition, a legal case report, a computer program, etc). This can be a work that is being quoted or referenced in detail (i.e. a citation), or it can just be a work that is mentioned in passing.

A person’s name is not the title of a work — even if people call that person a piece of work — and the element must therefore not be used to mark up people’s names.

I disagree.

In the examples above, it’s pretty clear that I, Pencil and Warlock Of Firetop Mountain are valid use cases for the cite element according to the HTML5 definition; they are titles of works. But what about Clippy or Little Moo or Slackbot? They’re not people …but they’re not exactly titles of works either.

If I were to mark up a dialogue between Eliza and a human being, should I only mark up Eliza’s remarks with cite? In text transcripts of conversations with Alexa, Siri, or Cortana, should only their side of the conversation get attributed as a source? Or should they also be written without the cite element because it must not be used to mark up people’s names …even though they are not people, according to conventional definition.

It’s downright botist.

New edition

Six years ago I wrote a book and the brand new plucky upstart A Book Apart published it.

Six years! That’s like a geological age in internet years.

People liked the book. That’s very gratifying. I’m quite proud of it, and it always gives me a warm glow when someone tells me they enjoyed reading it.

Jeffrey asked me a while back about updating the book for a second edition—after all, six years is crazy long time for a web book to be around. I said no, because I just wouldn’t have the time, but mostly because—as the old proverb goes—you can step in the same river twice. Proud as I am of HTML5 For Web Designers, I consider it part of my past.

“What about having someone else update it?” Well, that made me nervous. I feel quite protective of my six year old.

“What about Rachel Andrew?” Ah, well, that’s a different story! Absolutely—if there’s one person I trust to bring the up to date, it’s Rachel.

She’s done a fine, fine job. The second edition of HTML5 For Web Designers is now available.

I know what you’re going to ask: how much difference is there between the two editions? Well, in the introduction to the new edition, I’m very pleased to say that Rachel has written:

I’ve been struck by how much has remained unchanged in that time.

There’s a new section on responsive images. That’s probably the biggest change. The section on video has been expanded to include captioning. There are some updates and tweaks to the semantics of some of the structural elements. So it’s not a completely different book; it’s very much an update rather than a rewrite.

If you don’t have a copy of HTML5 For Web Designers and you’ve been thinking that maybe it’s too out-of-date to bother with, rest assured that it is now bang up to date thanks to Rachel.

Jeffrey has written a lovely new foreword for the second edition:

HTML5 for Web Designers is a book about HTML like Elements of Style is a book about commas. It’s a book founded on solid design principles, and forged at the cutting edge of twenty-first century multi-device design and development.

Placehold on tight

I’m a big fan of the placeholder attribute introduced in HTML5. In my book, I described the cowpath it was paving:

  1. When a form field has no value, insert some placeholder text into it.
  2. When the user focuses on that field, remove the placeholder text.
  3. If the user leaves the field and the field still has no value, reinstate the placeholder text.

That’s the behaviour that browsers mimicked when they began implementing the native placeholder functionality. I think Opera was first. Now all the major browsers support it.

But in some browsers, the details of that behaviour have changed slightly. In Chrome and Safari, when the user focuses on the field, the placeholder text remains. It’s not until the user actually begins to type that the placeholder text is removed.

Now, personally speaking, I’m not keen on this variation. It seems that I’m not alone. In an email to the WHATWG, Markus Ernst describes the problems that he’s noticed in user-testing where users are trying (and, of course, failing) to select the placeholder text in order to delete it before they begin typing.

It seems that a relevant number of users do not even try to start typing as long as the placeholder text remains visible.

But this isn’t so clear-cut. A quick straw poll at the Clearleft showed that opinions were divided on this. Some people prefer the newer behaviour …however it quickly became apparent that the situations they were thinking of were examples of where placeholder has been abused i.e. attempt to act as a label for the form field. In that situation, I agree, it would definitely be more useful for the labelling text to remain visible for as long as possible. But that’s not what placeholder is for. The placeholder attribute is intended to show a short hint (such as an example value)—it should be used in addition to a label; not instead of a label. I tend to use example content in my placeholder value and I nearly always begin with “e.g.”:

<label for="fn">Your Name</label>
<input id="fn" name="fn" type="text" placeholder="e.g. Joe Bloggs">

(Don’t forget: generating placeholders from datalists can be a handy little pattern.)

So if you’re using placeholder incorrectly as a label, then the WebKit behaviour is probably what you want. But if you’re using placeholder as intended, then the behaviour in the other browsers is probably more desirable. If you want to get Safari and Chrome to mimic the behaviour of the other browsers, here’s a handy bit of CSS (from that same thread on the WHATWG mailing list):

[placeholder]:focus::-webkit-input-placeholder {
  color: transparent;

You can see that in action on search forms at The Session for recordings, events, discussions, etc.

Now, if you do want your label—or input mask—to appear within your form field and remain even when the user focuses on the field, go ahead and do that. Use a label element with some CSS and JavaScript trickery to get the effect you want. But don’t use the placeholder attribute.

The main issue

The inclusion of a main element in HTML has been the subject of debate for quite a while now. After Steve outlined the use cases, the element has now landed in the draft of the W3C spec. It isn’t in the WHATWG spec yet, but seeing as it is being shipped in browsers, it’s only a matter of time.

But I have some qualms about the implementation details so I fired off an email to the HTML working group with my concerns about the main element as it is current specced.

I’m curious as to why its use is specifically scoped to the body element rather than any kind of sectioning content:

Authors must not include more than one main element in a document.

I get the rationale behind the main element: it plugs a gap in the overlap between native semantics and ARIA landmark roles (namely role="main"). But if you look at the other elements that map to ARIA roles (header, footer, nav), those elements can be used multiple times in a single document by being scoped to their sectioning content ancestor.

Let’s say, for example, that I have a document like this, containing two header elements:

 <header>Page header</header>
 Page main content starts here
  <header>Section header</header>
  Section main content
 Page main content finishes here

…only the first header element (the one that’s scoped to the body element) will correspond to role="banner", right?

Similarly, in this example, only the final footer element will correspond to role=”contentinfo”:

 <header>Page header</header>
 Page main content starts here
  <header>Section header</header>
  Section main content
  <footer>Section footer</footer>
 Page main content finishes here
 <footer>Page footer</footer>

So what I don’t understand is why we can’t have the main element work the same way i.e. scope it to its sectioning content ancestor so that only the main element that is scoped to the body element will correspond to role="main":

 <header>Page header</header>
  Page main content starts here
   <header>Section header</header>
   <main>Section main content</main>
   <footer>Section footer</footer>
  Page main content finishes here
 <footer>Page footer</footer>

Here are the corresponding ARIA roles:

 <header>Page header</header> <!-- role="banner" -->
 <main>Page main content</main> <!-- role="main" -->
 <footer>Page footer</footer> <!-- role="contentinfo" -->

Why not allow the main element to exist within sectioning content (section, article, nav, aside) the same as header and footer?

 <header>Section header</header> <!-- no corresponding role -->
 <main>Section main content</main> <!-- no corresponding role -->
 <footer>Section footer</footer> <!-- no corresponding role -->

Deciding how to treat the main element would then be the same as header and footer. Here’s what the spec says about the scope of footers:

When the nearest ancestor sectioning content or sectioning root element is the body element, then it applies to the whole page.

I could easily imagine the same principle being applied to the main element. From an implementation viewpoint, this is already what browsers have to do with header and footer. Wouldn’t it be just as simple to apply the same parsing to the main element?

It seems a shame to introduce a new element that can only be used zero or one time in a document …I think the head and body elements are the only other elements with this restriction (and I believe the title element is the only element that is used precisely once per document).

It would be handy to be able to explicitly mark up the main content of an article or an aside—for exactly the same reasons that it would be useful to mark up the main content of a document.

So why not?

Figuring out

A recent simplequiz over on HTML5 Doctor threw up some interesting semantic issues. Although the figure element wasn’t the main focus of the article, a lot of the comments were concerned with how it could and should be used.

This is a subject that has been covered before on HTML5 Doctor. It turns out that we may have been too restrictive in our use of the element, mistaking some descriptive text in the spec for proscriptive instruction:

The element can thus be used to annotate illustrations, diagrams, photos, code listings, etc, that are referred to from the main content of the document, but that could, without affecting the flow of the document, be moved away from that primary content, e.g. to the side of the page, to dedicated pages, or to an appendix.

Steve and Bruce have been campaigning on the HTML mailing list to get the wording updated and clarified.

Meanwhile, in an unrelated semantic question, there was another HTML5 Doctor article a while back about quoting and citing with blockquote and its ilk.

The two questions come together beautifully in a blog post on the newly-redesigned A List Apart documenting this pattern for associating quotations and authorship:

 <blockquote>It is the unofficial force—the Baker Street irregulars.</blockquote>
 <figcaption>Sherlock Holmes, <cite>Sign of Four</cite></figcaption>

Although, unsurprisingly, I still take issue with the decision in HTML5 not to allow the cite element to apply to people. As I’ve said before we don’t have to accept this restriction:

Join me in a campaign of civil disobedience against the unnecessarily restrictive, backwards-incompatible change to the cite element.

In which case, we get this nice little pattern combining figure, blockquote, cite, and the hCard microformat, like this:

 <blockquote>It is the unofficial force—the Baker Street irregulars.</blockquote>
 <figcaption class="vcard"><cite class="fn">Sherlock Holmes</cite>, <cite>Sign of Four</cite></figcaption>

Or like this:

 <blockquote>Join me in a campaign of civil disobedience against the unnecessarily restrictive, backwards-incompatible change to the cite element.</blockquote>
 <figcaption class="vcard"><cite class="fn">Jeremy Keith</cite>, <a href="http://24ways.org/2009/incite-a-riot/"><cite>Incite A Riot</cite></a></figcaption>


I remember when Ajax started gaining traction on the web and in the minds of developers. One of the factors that web developers suddenly had to think about was giving feedback to the user when a request was made to the server.

Normally this is something that the browser takes care of (with its rotating letter “e” or its sweeping lighthouse fresnel lens or whatever method your chosen browser uses). But once you decide to use Ajax to make a request to the server, you’re effectively saying “Hey browser, it’s okay; I got this.”

And so web developers everywhere began to recreate loading indicators that were so popular on Flash sites. Some of them are very clever, created entirely in CSS.

This is a pattern that has been codified into HTML itself. We now have a progress element. This can be used to display fine-grained progress if you give it value and max attributes, or you can simply use it without any attributes to indicate that something is happening …perfect for those Ajax requests.


What I like about this element is that you can put fallback content in between the opening and closing tags. So let’s say you’re currently using an animated .gif to show that some content is being requested via Ajax:

<img src="spinner.gif" alt="Loading...">

Now you can wrap that within a progress element:

<progress><img src="spinner.gif" alt="Loading..."></progress>

Modern browsers show the native progress indicator. Older browsers show the animated .gif.

Of course, right now your ability to style that native progress indicator is limited (the shadow DOM may change that) but, as I pointed out in my book, that may not be a bad thing:

Remember, the web isn’t about control. If a visitor to your site is familiar with using a browser’s native form doodad, you won’t be doing them any favors if you override the browser functionality with your own widget, even if you think your widget looks better.

Scrollin’, scrollin’, scrollin’

A few weeks ago, when I changed how the front page of this site works, I wrote about “streams”, infinite scrolling, and the back button:

Anyway, you’ll notice that the new home page of adactio.com is still using pagination. That’s related to another issue and I suspect that this is the same reason that we haven’t seen search engines like Google introduce stream-like behaviour instead of pagination for search results: what happens when you’ve left a stream but you use the browser’s back button to return to it?

In all likelihood you won’t be returned to the same spot in the stream that were in before. Instead you’re more likely to be dumped back at the default list view (the first ten or twenty items).

That’s exactly what Kyle Kneath is trying to solve with this nifty experiment with infinite scroll and the HTML5 History API. I should investigate this further. Although, like I said in my post, I would probably replace automatic infinite scrolling with an explicit user-initiated action:

Interpreting one action by a user—scrolling down the screen—as implicit permission to carry out another action—load more items—is a dangerous assumption.

Kyle’s code is available from GitHub (of course). As written, it relies on some library support—like jQuery—but with a little bit of tweaking, I’m sure it could be rewritten to remove any dependencies (hint, hint, lazy web).

Generating placeholders from datalists

Here’s a cute little markup pattern for ya.

Suppose you’ve got an input element that has—by means of a list attribute—an associated datalist. Here’s the example I used in HTML5 For Web Designers:

<label for="homeworld">Your home planet</label>
<input type="text" name="homeworld" id="homeworld" list="planets">
<datalist id="planets">
 <option value="Mercury">
 <option value="Venus">
 <option value="Earth">
 <option value="Mars">
 <option value="Jupiter">
 <option value="Saturn">
 <option value="Uranus">
 <option value="Neptune">

That results in a combo-box control in supporting browsers: as you type in the text field, you are presented with a subset of the options in the datalist that match what you are typing. It’s more powerful than a regular select, because you aren’t limited by the list of options: you’re free to type something that isn’t in the list (like, say, “Pluto”).

I’ve already written about the design of datalist and how you can use a combination of select and input using the same markup to be backward-compatible. I like datalist.

I also like the placeholder attribute. Another recent addition to HTML, this allows you to show an example of the kind of content you’d like the user to enter (note: this is not the same as a label).

It struck me recently that all the options in a datalist are perfectly good candidates for placeholder text. In the example above, I could update the input element to include:

<input type="text" name="homeworld" id="homeworld" list="planets" placeholder="Mars">


<input type="text" name="homeworld" id="homeworld" list="planets" placeholder="Saturn">

I wrote a little piece of JavaScript to do this:

  1. Loop through all the input elements that have a list attribute.
  2. Find the corresponding datalist element (its ID will match the list attribute).
  3. Pick a random option element from that datalist.
  4. Set the placeholder value of the input to that option value.

Put that JavaScript at the end of your document (or link to it from the end of your document) and you’re all set. You might want to tweak it a little: I find it helps to preface placeholder values with “e.g.” to make it clear that this is an example value. You can do that by changing the last line of the script:

input.setAttribute('placeholder','e.g. '+value);

You also might want to show more than one possible value. You might want the placeholder value to read “e.g. Mercury, Venus, Earth, etc.” …I’ll leave that as an exercise for the reader.

One moment

I use my walk to and from work every day as an opportunity to catch up on my Huffduffer podcast. Today I started listening to a talk I’ve really been looking forward to. It’s a Long Now seminar called Universal Access To All Knowledge by one of my heroes: Brewster Kahle, founder of The Internet Archive.

Brewster Kahle: Universal Access to All Knowledge — The Long Now on Huffduffer

As expected, it’s an excellent talk. I caught the start of it on my walk in to work this morning and I picked up where I left off on my walk home this evening. In fact, I deliberately didn’t get the bus home—despite the cold weather—so that I’d get plenty of listening done.

Round about the 23 minute mark he starts talking about Open Library, the fantastic project that George worked on to provide a web page for every book. He describes how it works as a lending library where an electronic version of a book can be checked out by one person at a time:

You can click on: hey! there’s this HTML5 For Web Designers. We bought this book—we bought this book from a publisher such that we could lend it. So you can say “Oh, I want to borrow this book” and it says “Oh, it’s checked out.” Darn! And you can add it to your list and remind yourself to go and get it some other time.

Holy crap! Did Brewster Kahle just use my book to demonstrate Open Library‽

It literally stopped me in my tracks. I stopped walking and stared at my phone, gobsmacked.

It was a very surreal moment. It was also a very happy moment.

Now I’m documenting that moment—and I don’t just mean on a third-party service like Twitter or Facebook. I want to be able to revisit that moment in the future so I’m documenting it at my own URL …though I’m very happy that the Internet Archive will also have a copy.

Months and years

While I was in San Francisco for the last Event Apart of the year in December, Luke pulled me aside while he was preparing for his A Day Apart workshop on mobile web design. As befits the man who literally wrote the book on web forms and also wrote the the book on mobile-first design, Luke was planning to spend plenty of time covering input on mobile devices and he wanted my opinion on one of the patterns he was going to mention.

Let’s say you’ve got your typical checkout form asking for credit card details. The user is going to need to specify the expiry date of their credit card, something that historically would have been done with select elements, like so:

With the introduction of the new input types in HTML5, we can now just use input type="month".

That’s particularly nice on mobile devices that support input type="month" like Mobile Safari since iOS5.

input type="month"

But the behaviour on non-supporting browsers would be to display just like input type="text" …not ideal for inputting a date.

So the pattern that Luke proposed was to start with the traditional double drop-downs for month and year, and then use feature detection to replace them with input type="month" in supporting browsers.

That was an angle I hadn’t thought of. Usually when I’m implementing new HTML5 input types (like input type="number") I put the new type in the markup and then try to come up with JavaScript polyfills for older non-supporting browsers. In this case though, the old-fashioned way is what goes in the markup and JavaScript does the enhancing for newer browsers.

The only downside is that some the desktop browsers that do support input type="month" do so in a way that—from a UI standpoint—seems like a step backwards from simply having two selects: Safari displays it with a spinner control like input type="number", while Opera shows an entire Calendar (days’n’all).

Anyway, I threw a quick hack together as a proof of concept so you can see it in action. I’m sure you can improve upon it. Feel free to do so.

Pursuing semantic value

Divya Manian, one of the super-smart web warriors behind HTML5 Boilerplate, has published an article on Smashing Magazine called Our Pointless Pursuit Of Semantic Value.

I’m afraid I have to agree with Patrick’s comment when he says that the abrasive title, the confrontational tone and strawman arguments at the start of the article make it hard to get to the real message.

But if you can get past the blustery tone and get to the kernel of the article, it’s a fairly straightforward message: don’t get too hung up on semantics to the detriment of other important facets of web development. Divya clarifies this in a comment:

Amen, this is the message the article gets to. Not semantics are useless but its not worth worrying over minute detail on.

The specific example of divs and sectioning content is troublesome though. There is a difference between a div and a section or article (or aside or nav). I don’t just mean the semantic difference (a div conveys no meaning about the contained content whereas a section element is specifically for enclosing thematically-related content). There are also practical differences.

A section element will have an effect on the generated outline for a document (a div will not). The new outline algorithm in HTML5 will make life a lot easier for future assistive technology and searchbots (as other people mentioned in the comments) but it already has practical effects today in some browsers in their default styling.

Download the HTML document I’ve thrown up at https://gist.github.com/1360458 and open it in the latest version of Safari, Chrome or Firefox. You’ll notice that the same element (h1) will have different styling depending on whether it is within a div or within a section element (thanks to -moz-any and -webkit-any CSS declarations in the browser’s default stylesheets).

So that’s one illustration of the practical difference between div and section.

Now with that said, I somewhat concur with the conclusion of “when in doubt, just use a div”. I see far too many documents where every div has been swapped out for a section or an article or a nav or an aside. But my reason for coming to that conclusion is the polar opposite of Divya’s reasoning. Whereas Divya is saying there is effectively no difference between using a div and using sectioning content, the opposite is the case: it makes a big difference to the document’s outline. So if you use a section or article or aside or nav without realising the consequences, the results could be much worse than if you had simply used a div.

I also agree that there’s a balance to be struck in the native semantics of HTML. In many ways its power comes from the fact that it is a limited—but universally understood by browsers—set of semantics. If we had an element for every possible type of content, the language would be useless. Personally, I’m not convinced that we need a section element and an article element: the semantics of those two elements are so close as to be practically identical.

And that’s the reason why right now is exactly the time for web developers to be thinking about semantics. The specification is still being put together and our collective voice matters. If we want to have well-considered semantic elements in the language, we need to take the time to consider the effects of every new element that could potentially be used to structure our content.

So I will continue to stop and think when it comes to choosing elements and class names just as much as I would sweat the details of visual design or the punctation in my copy or the coding style of my JavaScript.


When I first heard that Hixie had removed all traces of the time element from the ongoing HTML spec, my knee-jerk reaction was “This is a really bad idea!” But I decided not to jump in without first evaluating the arguments for and against the element’s removal. That’s what I’ve been doing over the past week and my considered response is:

This is a really bad idea!

The process by which the element was removed is quite disturbing:

  1. Hixie (as a contributer) opens a bug proposing that the time element be replaced with the more general data element.
  2. Lots of people respond, almost unanimously pointing out the problems with that proposal.
  3. Hixie (as the editor) goes ahead and does what exactly what he wanted anyway.

Technically that’s exactly how the WHATWG process works. The editor does whatever he wants:

This is not a consensus-based approach — there’s no guarantee that everyone will be happy! There is also no voting.

Most of the time, this works pretty well. It might not be fair but it seems to work more efficiently than the W3C’s consensus-based approach. But in this case the editor’s unilateral decision is fundamentally at odds with the most important HTML design principle, the priority of constituencies:

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone.

The specifier (Hixie) is riding roughshod over the concerns of authors.

I’m particularly concerned by the uncharacteristically muddy thinking behind Hixie’s decision. There are two separate issues here:

  1. Is the time element useful?
  2. Do we need a more general data element?

Hixie conflates these two questions.

He begins by bizarrely making the claim that time hasn’t had much uptake. This is demonstrably false. It’s already shipping in Drupal builds and Wordpress templates as well as having parser support in services and at least one browser. If anything, time is one of the more commonly used and understood elements in HTML5.

There’s a very good reason for that: it fulfils a need that authors have had for a long time—the ability to make a timestamp that is human and machine-readable at the same time. That’s the use case that the microformats community has been trying to solve with the abbr design pattern and the value-class pattern. Those solutions are okay, but not nearly as elegant and intuitive as having a dedicated time element.

Crucially the time element didn’t just specify the mechanism for encoding a machine-readable timestamp, it also defined the format, namely a subset of ISO 8601. That’s exactly the kind of unambiguous documentation that makes a specification useful.

Hixie correctly points out that there are cases for human and machine-readable data other than dates and times. He incorrectly jumps to the conclusion that the time is therefore a failure.

I think he’s right that there probably should be a dedicated element for marking up this kind of data. We already have the meta element but the fact that it’s a standalone element makes it tricky to explicitly associate the human-readable text. So the introduction of a new data may very well turn out to be a good idea. But it does not need to be introduced at the expense of the more specific time element.

I think there’s a comparison to be made with sectioning content. We’ve got the generic section element but then we also have the more specific nav, aside and article elements that can be thought of specialised forms of section. By Hixie’s logic, there’s no reason to have nav, aside and article when a section element has the same effect on the outlining algorithm. But we have those elements because they cover very common use cases.

Hixie’s reductio ad absurdum argument is that if there is a special element for timestamps, we should also have an element for every other possible piece of machine-readable data. If that’s the case we should also have an infinite amount of sectioning content elements: blogpost, comment, chapter, etc. Instead we have just the four elements—section, article, aside and nav—because they represent the most common use cases …perhaps 80%?

The use case that the time element satisfies (human and machine-readable timestamps) is very, very common. The actual mechanism may vary (the time element itself, the abbr pattern, etc.) but the cow path is very much in need of paving.

There’s also a disturbingly Boolean trait to Hixie’s logic. He lumps all machine-readable data into the same bucket. If he had paid attention to Tantek’s research on abstracting microformat vocabularies, he would have seen that it’s a bit more fine-grained than that. There’s a difference between straightforward name/value pairs (like fn or summary), URL values (like photo) and timestamps (like dtstart). The thing that distinguishes timestamps is that they have an existing predefined machine-readable format.

To strengthen his position Hixie introduced two strawmen into the discussion, claiming that the time element was intended to allow easier styling of dates and times with CSS and to also allow conversion of HTML documents into Atom. Those use cases are completely tangential to the fundamental reason for the existence of the time element. Hixie seems to have forgotten that he himself once had it enshrined in the spec that the purpose of the element was to allow users to add events to their calendars. I pointed out that this was an example usage of the more general pattern of machine-readable dates and times so the text of the spec was updated accordingly:

This element is intended as a way to encode modern dates and times in a machine-readable way so that, for example, user agents can offer to add birthday reminders or scheduled events to the user’s calendar.

No mention of styling. No mention of converting documents to Atom.

I’m not the only one who is perplexed by Hixie’s bullheaded behaviour. Steve Faulkner has entered a revert request on the W3C side of things (he’s a braver man than me: the byzantine W3C process scares me off). Ben summed up the situation nicely on Twitter. You can find plenty of other reactions on Twitter by searching for the hashtag #occupyhtml5. Bruce has written down his thoughts and the follow-on comments are worth reading. This reaction from Stephanie is both heartbreaking and completely understandable:

I have been pretty frustrated by this change. In fact, when I read the entire thread on the debacle, it nearly made me want to give up on teaching, and using HTML5. What’s the point when there’s really no discussion? A single person brings something up. Great arguments are made. And then he just does what he originally wanted to do anyway.

I’d like to think that a concerted campaign could sway Hixie but I don’t hold out much hope. Usually there’s only one way to get through to him and that’s by presenting data. Rightly so. In this case however, Hixie is ignoring the data completely. He’s also wilfully violating the fundamental design principles behind HTML5.

So what can we do? Well, just as with the incorrectly-defined semantics of the cite element we can make a stand and simply carry on using the time element in our web pages. If we do, then we’ll see more parsers and browsers implementing support for the time element. The fact that our documentation has been ripped away makes this trickier but it’s such a demonstrably useful addition to HTML that we cannot afford to throw it away based on the faulty logic of one person.

Hixie once said:

The reality is that the browser vendors have the ultimate veto on everything in the spec, since if they don’t implement it, the spec is nothing but a work of fiction. So they have a lot of influence—I don’t want to be writing fiction, I want to be writing a spec that documents the actual behaviour of browsers.

Keep using the time element.

HTML5 For Web Designers

I’ve just finished speaking at An Event Apart in Washington DC (well, technically it’s in Alexandria, Virginia but let’s not quibble over details).

I was talking about design principles, referencing a lot of the stuff that I’ve gathered together at principles.adactio.com. I lingered over the HTML design principles and illustrated them with examples from HTML5.

It’s been a year and a half now since HTML5 For Web Designers was released and I figured it was about time that it should be published in its natural format: HTML.

Ladies and gentlemen, I give you: HTML5forWebDesigners.com.

Needless to say, it’s all written in HTML5 making good use of some of the new semantic elements like section, nav and figure. It’s also using some offline storage in the shape of appcache. So if you visit the site with a browser that supports appcache, you’ll be able to browse it any time after that even if you don’t have an internet connection (and if you’re trying it on an iOS device, feel free to add it to your home screen so it’s always within easy reach).

You can read it on a desktop browser. You can read it in a mobile browser. You can read it in Lynx if you want. You can print it out. You can read it on the Kindle browser. You can read it on a tablet.

And if you like what you read and you decide you want to have a physical souvenir, you can buy the book and read it on paper.

HTML5 For Web Designers

Citation needed

Over on the HTML5 Doctor site, Oli has written a great article called Quoting and citing with <blockquote>, <q>, <cite>, and the cite attribute.

Now, I still stand by my criticism of the way the cite element has been restrictively redefined in HTML5 such that it’s not supposed to be used for marking up a resource if that resource is a person. But I think that Oli has done a great job in setting out the counter-argument:

By better defining <cite>, we increase the odds of getting usable data from it, though we now need different methods to cover these other uses.

Oli’s article also delves into the blockquote element, which is defined in HTML5 as a sectioning root.

Don’t be fooled by the name: sectioning roots are very different to sectioning content in a fundamental way. Whereas sectioning content elements—section, article, nav and aside—are all about creating an explicit outline for the document from the headings contained within the sectioning content (using the new outline algorithm), the headings within sectioning roots (blockquote, td, fieldset, figure, etc.) don’t contribute to the document outline at all! But what sectioning roots and sectioning content have in common is that they both define the scope of the header and footer elements contained within them.

The footer element is defined as containing information about its section such as who wrote it, links to related documents, copyright data, and the like.

This gives a rise to rather lovely markup pattern that’s used on HTML5 Doctor: why not use the footer element within a blockquote to explicitly declare its provenance:

<p>The people that designed .mobi were smoking crack.</p>
<footer>&mdash;<cite class="vcard">
<a class="fn url" href="http://tantek.com/">Tantek Çelik</a>

(and yes, I am using the cite element to mark up a person’s name there).

Well, apparently that blockquote pattern is not allowed according to the spec:

Content inside a blockquote must be quoted from another source.

Because the content within the blockquote’s footer isn’t part of the quoted content, it shouldn’t be contained within the blockquote.

I think that’s a shame. So does Oli. He filed a bug. The bug was rejected with this comment:

If you want the spec to be changed, please provide rationale and reopen.

That’s exactly what Oli is doing. He has created a comprehensive document of block quote metadata from other resources: books, plays, style guides and so on.

Excellent work! That’s how you go about working towards a change in the spec—not with rhetoric, but with data.

That’s why my article complaining about the restrictions on the cite element is fairly pointless, but the wiki page that Tantek set up to document existing use cases is far more useful.

Drupalcon in Chi-town

The last time I was in Chicago the weather was rather lovely. I spent some time walking around, gaping up at the skyscrapers and exploring the city.

This time the weather has been a bit chillier. My attempts to venture out and explore the city on foot ended in defeat as I was beaten back to the warmer confines of the hotel playing host to Drupalcon.

My first day, as anticipated, was spent hunting down a mythical FedEx/Kinkos so I could print out workshop materials—paper-based exercises and HTML5 pocketbooks. With that task achieved—at no minor expense; charging for ink on paper is clearly a lucrative business model—imagine my surprise when I turned up the next day for my workshop and I was handed the printouts of my workshop exercises; the same materials I had been told I would have to print out for myself. Clearly, I didn’t get the memo …possibly because said memo was never conjured into existence.

Apart from that breakdown in communication, the HTML5 workshop went smoothly. Better than smoothly. The attendees were asking excellent questions and some great discussions emerged. Running a workshop can be very tiring but it can also be very rewarding.

The next morning I attended Dries’s pep-talk keynote. It was like experiencing a milder, kinder more collaborative version of Scientology (I kid, I kid; ‘twas a lovely State of the Union address).

Part of the keynote was a compilation of answers to the question “What is Drupal?” put to a backing track of a suitably schmaltzy motivational song (David Brent would’ve been jealous). As I watched the quotes appear on screen, I noticed that one of them was attributed to me. Except… I have no recollection of ever saying or writing something along the lines of:

Drupal makes complex things easy and easy things complex.

Sure enough, it turns out that the quote was misattributed to me.

I guess it sounds like something I could have said. In fact, I could justify the paraphrased quote thusly: If you want to get a database-driven site up and running quickly, you can do that with Drupal simply by pressing a few buttons and pulling the software equivalent of levers. However, if you want to edit, for example, the way that a particular form field has been marked up, or you’d like to remove some superfluous div elements …well, for that you need to really know what you’re doing.

Hence, Drupal makes complex things (like setting up a website) easy and easy things (like editing some markup) complex.

I had quite a few conversations with people about the nature of frameworks and Drupal in particular. Personally, it doesn’t appeal to me, not just because it doesn’t output the kind of markup that I’d like. It doesn’t appeal to me simply because it outputs any markup at all. I prefer something more like Django that takes care of abstracting away all that server-side complexity and database work, but leaves it entirely up to you to create the front-end (well, except for the admin interface).

But that’s just me. And I totally understand that for other people, that just isn’t a priority and Drupal’s ability to deliver an entire site, front-end included, is a godsend. Different frameworks will appeal to different people—the trick is in finding a framework that matches the way that you approach a problem. A framework is, after all, supposed to be a tool to help you get work done faster. No one framework is suitable for all projects and no one framework can possibly hope to appeal to everyone.

Yet, at Drupalcon, I got the impression that Drupal might be attempting to do just that. Rather than focusing on the kind of sites for which Drupal is particularly well-suited, the goal appears to be nothing less than total domination of the web. I’m not sure that’s such a good idea. If you try to please literally everybody, I think you’ll probably end up pleasing nobody.

I did hear rumblings of the possibility of changing Drupal so that there would be no markup in its core release. Rather, different distributions (built on top of core) could be used to create the right kind of site; one distribution for news sites, another distribution for company websites, and so on. I like that idea. It would also make it easier for Drupal to adapt its output to different devices—something that Dries touched on his keynote.

Meanwhile Jen is spearheading an effort to update Drupal’s output to include HTML5 additions—new input types for forms, sectioning elements for content, and so on. She’s beginning by proposing some design principles. I believe this is a thoroughly excellent approach. At Jen’s Drupalcon core conversation I offered my feedback (and encouragement) on how the design principles are shaping up.

For the rest of Drupalcon, I found plenty to keep my interest. There was a significant design portion to the proceedings so even a non-Drupal person like me could find some great talks, like Samantha’s superb round-up of design techniques—I’ll be bringing some of those gems back to the Clearlefties.

My final night in Chicago was nigh-on perfect. Adrian had been in touch to let me know that his band would be playing in the historic Green Mill. I rustled up a little posse of designers and we spent the evening listening to superb gypsy jazz in an amazing venue that was once a favourite haunt of Al Capone (rumour has it that the grumpy doorman is related). A nightcap of beer and cheezborger, cheezborger, cheezborger at The Billy Goat Tavern was the coup de grace.

Now I bid farewell to Chicago and hello to Austin, where the weather is significantly warmer.

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!

Marklar Malkovich Smurf

  • Webmonkey: HTML5 Gains Logo, Loses Meaning

    It doesn’t really matter if the New York Times thinks CSS 3 or SVG are HTML5, but we’d like to think that at least the organization in charge of describing what is, and is not, HTML5 would make some effort to distinguish between tools. Lumping everything together is as silly as a carpenter referring to every tool in their toolkit as “a hammer.”

  • CNET News: W3C’s new logo promotes HTML5—and more

    Curiously, though, the standards group—the very people one might expect to have the narrowest interpretation of what exactly HTML5 means—instead say it stands for a swath of new Web technologies extending well beyond the next version of Hypertext Markup Language.

  • GigaOM: The Truth Behind HTML5′s New Logo Fiasco

    It’s as if the government suddenly announced that from today, all vegetables will be called potatoes, just because some vegetables are potatoes.

  • The Register: W3C tackles HTML5 confusion with, um, more confusion

    And much like Apple, Google, and Microsoft before it, the organization that oversees HTML5 has confused it with all sorts of other web standards.

  • The Web Standards Project: HTML5 logo: be proud, but don’t muddy the waters!

    Now the W3C has come out and essentially condoned the branding of everything from CSS to actual HTML5 to WOFF as “HTML5”. We can’t imagine a single action that will cause more confusion than this misguided decision (and the W3C has produced some pretty impenetrable specs in its time)

  • Roger Johansson: HTML5 now includes CSS3, SVG and WOFF?

    This move from the W3C will not help people differentiate between very different technologies.

  • CSS Squirrel: HTML5 Super Friends Assemble!

    The logo is pretty, but the intentional use of HTML5 as a blanket term for other modern web technologies is a crock. Newspapers making merry with the term is one thing, but a web standards organization?

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.

Badge of shame

The W3C have unveiled a logo for HTML5. I’m not sure the world needs such a logo, but I think it looks pretty good. It reminds me of some of the promotional materials used by the Web Standards Project back in the day—simple bold lines that work well at small sizes, with a whiff of Russian constructivism.

But I take issue with the scope of what this logo is supposed to represent. From the Frequently Asked Questions:

The logo is a general-purpose visual identity for a broad set of open web technologies, including HTML5, CSS, SVG, WOFF, and others.

What. A. Crock.

What we have here is a deliberate attempt to further blur the lines between separate technologies that have already become intertwingled in media reports.

Don’t get me wrong; I don’t mind if marketers and journalists use HTML5 to mean everything under the sun, but I expect working web developers to be able to keep specs separate in their mind. If Apple or Google were pushing this kind of fuzziness, I wouldn’t mind …but this is coming straight from the horse’s mouth (or, in this case, straight from the horse’s ass).

“But,” cry the cheerleaders of ambiguity, “we need some kind of term to refer to HTML5 plus CSS3!”

Citation needed.

We never needed a term to refer to “XHTML 1.0 plus CSS2.1” or “HTML4.01 plus JavaScript” or “any combination of front-end technologies.” Why this sudden all-conquering need for a term that covers so many different technologies as to be completely meaningless? As I said before:

Clarifying what is and isn’t in HTML5 isn’t pedantry for pedantry’s sake. It’s about communication and clarity, the cornerstones of language.

But I guess I’ve lost that battle. Now even the W3C are intent on blurring the distinction between different technologies to the extent that using a particular font file format qualifies as HTML5.

So now what do I do when I want to give a description of a workshop, or a talk, or a book that’s actually about HTML5? If I just say “It’s about HTML5,” that will soon be as meaningful as saying “It’s about Web 2.0,” or “It’s about leveraging the synergies of disruptive transmedia paradigms.” The term HTML5 has, with the support of the W3C, been pushed into the linguistic sewer of buzzwordland. Instead, I will try using phrases:

  • “HTML5, no really”,
  • “The parts of HTML5 that are documented in the specification labelled HTML5”,
  • “Actual HTML5”

But I think the term that’s going to be most accurate is:

  • “HTML”

Update: The W3C have changed their mind. Yay!