Journal tags: html5

It’s a bit of a cliché to talk about living in the future. It’s also a bit pointless. After all, any moment after the big bang is a future when viewed from any point in time before it.

Still, it’s kind of fun when a sci-fi date rolls around. Like in 2015 when we reached the time depicted in Back To The Future 2, or in 2019 when we reached the time of Blade Runner.

In 2022 we are living in the future of web standards. Again, technically, we’re always living in the future of any past discussion of web standards, but this year is significant …in a very insignificant way.

It all goes back to 2008 and an interview with Hixie, editor of the HTML5 spec at the WHATWG at the time. In it, he mentioned the date 2022 as the milestone for having two completely interoperable implementations.

The far more important—and ambitious—date was 2012, when HTML5 was supposed to become a Candidate Recommendation, which is standards-speak for done’n’dusted.

But the mere mention of the year 2022 back in the year 2008 was too much for some people. Jeff Croft, for example, completely lost his shit (Jeff had a habit of posting angry rants and then denying that he was angry or ranty, but merely having a bit of fun).

The whole thing was a big misunderstanding and soon irrelevant: talk of 2022 was dropped from HTML5 discussions. But for a while there, it was fascinating to see web designers and developers contemplate a year that seemed ludicriously futuristic. Jeff wrote:

God knows where I’ll be in 13 years. Quite frankly, I’ll be pretty fucking disappointed in myself (and our entire industry) if I’m writing HTML in 13 years.

That always struck me as odd. If I thought like that, I’d wonder what the point would be in making anything on the web to begin with (bear in mind that both my own personal website and The Session are now entering their third decade of life).

I had a different reaction to Jeff, as I wrote in 2010:

Many web developers were disgusted that such a seemingly far-off date was even being mentioned. My reaction was the opposite. I began to pay attention to HTML5.

But Jeff was far from alone. Scott Gilbertson wrote an angry article on Webmonkey:

If you’re thinking that planning how the web will look and work 13 years from now is a little bit ridiculous, you’re not alone.

Even if your 2022 ronc-o-matic web-enabled toaster (It slices! It dices! It browses! It arouses!) does ship with Firefox v22.3, will HTML still be the dominant language of web? Given that no one can really answer that question, does it make sense to propose a standard so far in the future?

(I’m re-reading that article in the current version of Firefox: 95.0.2.)

Brian Veloso wrote on his site:

Two-thousand-twenty-two. That’s 14 years from now. Can any of us think that far? Wouldn’t our robot overlords, whether you welcome them or not, have taken over by then? Will the internet even matter then?

From the comments on Jeff’s post, there’s Corey Dutson:

2022: God knows what the Internet will look like at that point. Will we even have websites?

Dan Rubin, who has indeed successfully moved from web work to photography, wrote:

I certainly don’t intend to be doing “web work” by that time. I’m very curious to see where the web actually is in 14 years, though I can’t imagine that HTML5 will even get that far; it’ll all be obsolete before 2022.

Joshua Works made a prediction that’s worryingly close to reality:

I’ll be surprised if website-as-HTML is still the preferred method for moving around the tons of data we create, especially in the manner that could have been predicted in 2003 or even today. Hell, iPods will be over 20 years old by then and if everything’s not run as an iPhone App, then something went wrong.

Someone with the moniker Grand Caveman wrote:

In 2022 I’ll be 34, and hopefully the internet will be obsolete by then.

Perhaps the most level-headed observation came from Jonny Axelsson:

The world in 2022 will be pretty much like the world in 2009.

The world in 2009 is pretty much like 1996 which was pretty much like the world in 1983 which was pretty much like the world in 1970. Some changes are fairly sudden, others are slow, some are dramatic, others subtle, but as a whole “pretty much the same” covers it.

The Web in 2022 will not be dramatically different from the Web in 2009. It will be less hot and it will be less cool. The Web is a project, and as it succeeds it will fade out of our attention and into the background. We don’t care about things when they work.

Now that’s a sensible perspective!

So who else is looking forward to seeing what the World Wide Web is like in 2036?

I must remember to write a blog post then and link back to this one. I have no intention of trying to predict the future, but I’m willing to bet that hyperlinks will still be around in 14 years.

Speaking of long bets…

I’m a big fan of HTML5’s datalist element and its elegant design. It’s a way to progressively enhance any input element into a combobox.

You use the list attribute on the input element to point to the ID of the associated datalist element.

<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">
</datalist>

It even works on input type="color", which is pretty cool!

The most common use case is as an autocomplete widget. That’s how I’m using it over on The Session, where the datalist is updated via Ajax every time the input is updated.

But let’s stick with a simple example, like the list of planets above. Suppose the user types “jup” …the datalist will show “Jupiter” as an option. The user can click on that option to automatically complete their input.

It would be handy if you could automatically submit the form when the user chooses a datalist option like this.

Well, tough luck.

The datalist element emits no events. There’s no way of telling if it has been clicked. This is something I’ve been trying to find a workaround for.

I got my hopes up when I read Amber’s excellent article about document.activeElement. But no, the focus stays on the input when the user clicks on an option in a datalist.

So if I can’t detect whether a datalist has been used, this best I can do is try to infer it. I know it’s not exactly the same thing, and it won’t be as reliable as true detection, but here’s my logic:

• Keep track of the character count in the input element.
• Every time the input is updated in any way, check the current character count against the last character count.
• If the difference is greater than one, something interesting happened! Maybe the user pasted a value in …or maybe they used the datalist.
• Loop through each of the options in the datalist.
• If there’s an exact match with the current value of the input element, chances are the user chose that option from the datalist.
• So submit the form!

Here’s how that translates into DOM scripting code:

document.querySelectorAll('input[list]').forEach( function (formfield) {
  var datalist = document.getElementById(formfield.getAttribute('list'));
  var lastlength = formfield.value.length;
  var checkInputValue = function (inputValue) {
    if (inputValue.length - lastlength > 1) {
      datalist.querySelectorAll('option').forEach( function (item) {
        if (item.value === inputValue) {
          formfield.form.submit();
        }
      });
    }
    lastlength = inputValue.length;
  };
  formfield.addEventListener('input', function () {
    checkInputValue(this.value);
  }, false);
});

I’ve made a gist with some added feature detection and mustard-cutting at the start. You should be able to drop it into just about any page that’s using datalist. It works even if the options in the datalist are dynamically updated, like the example on The Session.

It’s not foolproof. The inference relies on the difference between what was previously typed and what’s autocompleted to be more than one character. So in the planets example, if someone has type “Jupite” and then they choose “Jupiter” from the datalist, the form won’t automatically submit.

But still, I reckon it covers most common use cases. And like the datalist element itself, you can consider this functionality a progressive enhancement.

Today marks ten years since the publication of HTML5 For Web Designers, the very first book from A Book Apart.

I’m so proud of that book, and so honoured that I was the first author published by the web’s finest purveyors of brief books. I mean, just look at the calibre of their output since my stumbling start!

Here’s what I wrote ten years ago.

Here’s what Jason wrote ten years ago.

Here’s what Mandy wrote ten years ago.

Here’s what Jeffrey wrote ten years ago.

They started something magnificent. Ten years on, with Katel at the helm, it’s going from strength to strength.

Happy birthday, little book! And happy birthday, A Book Apart! Here’s to another decade!

Apple Inc. is my accidental marketing department.

On April 29th, 2010, Steve Jobs published his infamous Thoughts on Flash. It thrust the thitherto geek phrase “HTML5” into the mainstream press:

HTML5, the new web standard that has been adopted by Apple, Google and many others, lets web developers create advanced graphics, typography, animations and transitions without relying on third party browser plug-ins (like Flash). HTML5 is completely open and controlled by a standards committee, of which Apple is a member.

Five days later, I announced the first title from A Book Apart: HTML5 For Web Designers. The timing was purely coincidental, but it definitely didn’t hurt that book’s circulation.

Fast forward eight years…

On March 29th, 2018, Apple released the latest version of iOS. Unmentioned in the press release, this update added service worker support to Mobile Safari.

Five days later, I announced the 26th title from A Book Apart: Going Offline.

For a while now, quite a few people have cited Apple’s lack of support as a reason why they weren’t investigating service workers. That excuse no longer holds water.

I expect not understanding how progressive web apps are built (service workers, manifests, https) will be a skill deficit in 6-12 months, much like not understanding @RWD has been for a few of years.

— Lívia De Paula Labate (@livlab) April 15, 2018

Once again, the timing is purely coincidental. But it can’t hurt.

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.

What’s happening?

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.

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.

It looks like you’re writing a letter.

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.

Welcome to Adventure!! Would you like instructions?

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

ÆLFRED MECH HET GEWYRCAN

Ælfred ordered me to be made

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.

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.

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 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:

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

…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”:

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

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":

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

Here are the corresponding ARIA roles:

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

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

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

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?

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:

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

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:

<figure>
 <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>
</figure>

Or like this:

<figure>
 <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>
</figure>

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.

<progress></progress>

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.

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).

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">
</datalist>

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">

or:

<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.

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.

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.

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:

January February March April May June July August September October November December 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020

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.

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.

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.

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

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:

<blockquote>
<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>
</cite></footer>
</blockquote>

(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.

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.

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.