Adaptive images are the next unsolved mystery of Responsive Web Design. Do you send large high-res images suitable for retina dispays, which are scaled down on smaller, lower res devices and which therefore waste bandwidth? Or do you send low-res images, whch look grotty when scaled up to large screens or high-res displays? Authors have had to rely on elaborate hacks to send different content images (that is <img> in HTML rather than CSS background images) to different types of devices.

By November 2011, I was so frustrated that no specification body was considering the problem that I proposed a strawman <picture> element that re-used the mechanism of HTML5 <video> with its media queries to swap in different source files:

<picture alt="angry pirate">
   <source src=hires.png media="min-width:800px">
   <source src=midres.png media="min-width:480px">
   <source src=lores.png>
      <!-- fallback for browsers without support -->
      <img src=midres.png alt="angry pirate">
</picture>

Around the same time, others independently came to the same idea and were advised to set up a W3C community group to discuss it which they did. However, in January, the HTML5 editor, Ian Hickson, had said

What’s the use case for doing it for images in <img> elements? Typically <img> elements are for content images, where you don’t usually want to adapt anything.

Those web authors in the W3C Resposive Images Community Group soldiered on in frustration that they were they being ignored because the problem itself wasn’t seen as a problem. Then this week, Edward O’Connor of Apple suggested another method, using a new srcset attribute on the <img> element. This complemented a similar suggestion of his from February for img-set in CSS that is already being added to WebKit:

<img src="foo-lores.jpg"
     srcset="foo-hires.jpg 2x, foo-superduperhires.jpg 6.5x"
     alt="decent alt text for foo.">

The numbers “2″ and “6.5x” tell the browser the relative resolutions; foo-hires.jpg is 2x the resolution of foo-lores.jpg.

Only a few days later, a variant of Apple’s suggestion was added to the spec.

There are two major differences between <picture> and srcset. The most obvious is that srcset uses the <img> element, which is great because that’s the natural place for images, adaptive or not. (You can’t re-use the <video> + <source> pattern with <img> because it is an empty element so can’t have child elements. O’Connor’s solution uses attributes, which are fine.)

The other major difference is that it doesn’t use Media Queries. With Media Queries, the author is reponsible for thinking up every permuations of viewport size, orientation, dpi, colour depth, aspect ratio and the like, deciding how to cater for them (if at all), identifing the breakpoints and coding them up. This requires a lot of consideration by the author, and makes for verbose code; a page with 20 pictures, each with 5 Media Queries on 5 <source> elements quickly becomes a lot of code.

O’Connor wrote

Why provide a scale factor and not a media query? Well, media queries are claims about UA state, whereas here we’re asserting something about the relationship between the image assets. Also, User Agents should be free to use whichever asset they deem best suited to their current situation, taking into account not just “media-queriable things” like device resolution but also any scaling applied to the <img> with CSS, its width=”" and height=”" attributes, or even things like the current page zoom level.

I have a lot of sympathy with allowing the browser to make decisions about what it knows of the environment (network speed, latency, pixel density, orientation) to choose the best image for the job. The idea is that the author shouldn’t be expected to anticipate and cater for all those variables. What she can do is describe the things she knows about -the images, their size and pixel density- and the browser will make its choice.

That way, when we’re all living in space and looking a 3D holograms, the proximity to a black hole can be detected by the iDroid3000 device (black holes notoriously cause Web hologram negative timespace inversions) and the right image chosen; we don’t need to invent new media queries for event horizon proximity and retrospectively add it to our websites.

There are two problems with the srcset suggestion. The first is highly subjective, but many feel the same: as it exists in the current, first draft of the spec, the syntax is revolting:

<img src="face-600-200-at-1.jpeg" alt=""
srcset="face-600-200-at-1.jpeg 600w 200h 1x,
face-600-200-at-2.jpeg 600w 200h 2x,
face-icon.png 200w 200h">

Of course, this can be improved, and must be. This isn’t just about aesthetics. If the syntax is too weird, it will be used wrongly. As Dr Remy wrote, “Good to see authors have another microsyntax to learn. It’s not like they had any trouble with vendor-prefixes.”

The second problem is that authors don’t want to relinquish control. There are questions of art direction (see the section headed Do I care about art direction?), and many remain unconvinced that the Apple suggestion addresses that; proponents of srcset are convinced that it does address those use cases.

Debate continues, with a full and frank exchange of views. There are understandably hurt feelings, too, because some of those who laboured in the Community Group feel that their wishes and work have been ignored.

As one of those who proposed <picture>, I have a degree of attachment to it. That’s ego. (In fact, I’d be delighted if it were called the <yayBruce> element, but I’m resigned to the unfairness of life.) But I don’t really care which syntax makes the spec, as long as it addresses the majority of use cases and it is usable by authors. I’m just glad we’re discussing the adaptive image problem at all.

So, get involved. Read the discussions and say your piece. And once the dust has settled and the specification is looking stable, we Doctors will write up our diagnosis.

HTML5 adaptive images: end of round one originally appeared on HTML5 Doctor on May 16, 2012.

We’ve come a long way in the HTML5 specification’s steady march towards ratification and implementation. The WHATWG’s energy has recently been more on post-HTML5 features that are being added to “HTML The Living Standard”, plus tidying up HTML5 for Last Call. However we’re still not past losing (or gaining) an element, with last week seeing the removal of <time> and the addition of <data>.

<time> was originally added to allow dates and times to be machine readable, via the datetime attribute. This gives us human-readable content (“yesterday”) plus hidden machine-readable content (“2011-11-02”) with no accessibility problems. It allows for e.g. browsers to offer to localise dates. The pubdate attribute indicating an article’s date of publication was added for HTML to Atom conversion (also removed from HTML5 in this change), and would make it easy for search engines to sort by date. Having permitted dates and times specified in HTML5 (a subset of ISO 8601) allows a validator to check a datetime value is valid.

<time> has been one of the easier elements to understand for authors, as it’s semantically obvious. By comparison the microformats Class-Value pattern for datetimes is clunky.

HTML5 <time> element:

<time class="dtstart" datetime="2011-10-05T09:00Z">9am on October 5</time>

Microformats Value-Class pattern:

<span class="dtstart"><abbr class="value" title="09:00">9am</abbr> on <abbr class="value" title="2011-10-05">October 5</abbr></span>

<time> has been pretty widely used for weblog article publication dates, and has made it into WordPress and Drupal plus being used by Google for search results.

The issues raised about <time> by authors were mainly that it didn’t do everything: it didn’t cover ancient and vague times, time durations, and there was no “last updated” attribute equivalent to pubdate. The other problem is there are a bunch of other less common but similar kinds of data that would also benefit from being machine readable and validatable, such as weights and prices. Minting a new element for each one would (arguably) be a lot of work, so Ian Hickson has added a generic element for these use cases instead — the <data> element, with a required value attribute.

The data element represents its contents, along with a machine-readable form of those contents in the value attribute.

The value attribute contains the machine-readable equivalent of the element’s content. The <data> element can be used as-is as an element equivalent of data-* for marking up private data for scripts (although without the dataset API). It can also be used in conjunction with microdata vocabularies (and potentially microformats), in which case the format of the value attribute is specified by the vocabulary.

This is a welcome addition as it gives us an easy way to duplicate microformats’ Value-Class pattern for more than just the datetimes <time> allowed. However as part of introducing <data>, <time> together with datetime and pubdate have been dropped.

This is controversial, with our own Dr Bruce writing:

I think this is a bad decision

Steve Faulkner has requested this change be reverted, and comments on the Twitters and blogs (Bruce, WebMonkey, Zeldman) have been mostly ranging from shock to outrage.

This is because while <time> is semantically obvious, <data> is seen as an equivalent to <div> or <span>. However, “semantics for the sake of it” isn’t enough to justify being in the spec, despite the benefits. Another reason for the dismay is many people have had trouble pushing to use HTML5, and having an element removed gives fuel to anyone arguing HTML5 isn’t suitable for production.

<article>
 …
 <footer>Published <time pubdate datetime="2011-11-03">today</time>.</footer>
</article>

<article itemscope itemtype="http://schema.org/BlogPosting">
 …
 <footer>Published <data itemprop="datePublished" value="2011-11-03">today</data>.</footer>
</article>

Goodbye time, datetime, and pubdate. Hello data and value. originally appeared on HTML5 Doctor on November 2, 2011.

Before HTML5, <u> was solely for applying a presentational style of underlining to text. HTML 4 discouraged “font-style” or presentational elements, and even deprecated <u>, advising us to use CSS instead. Even before this, <u> was frowned upon as underlines are the browser default for links, and making normal text look like links gives users a bad case of clicky-clicky frustration. <u> was initially non-conforming in HTML5.

There are, however, a couple of non-link places where text is traditionally underlined to convey meaning, as the HTML5 specification’s definition mentions:

The u element represents a span of text with an unarticulated, though explicitly rendered, non-textual annotation, such as labeling the text as being a proper name in Chinese text (a Chinese proper name mark), or labeling the text as being misspelt.

Before we get to them, let’s quickly cover an unarticulated, though explicitly rendered, non-textual annotation. This means <u> is for when you are annotating something, but not explicitly saying what it is (WHATWG IRC, Ian Hickson) — the annotation’s meaning is implied by context.

<u class="pnm">屈原</u>放逐，乃賦<cite class="bnm">離騒</cite>。<u class="pnm">左丘</u>失明，厥有<cite class="bnm">國語</cite>。（司馬遷 《<cite>報任安書</cite>》）

.spelling-error {
  text-decoration: none;
  border-bottom: 1px dashed red;
}
.grammatical-error {
  text-decoration: none;
  border-bottom: 1px dashed green;
}
<p>hello doctor i am having a huge body <u class="spelling-error">oder</u> <u class="grammatical-error">it is smell really bad</u></p>

.spelling-error {
  text-decoration-line: underline;
  text-decoration-style: wavy;
  text-decoration-color: red;
}
.grammatical-error {
  text-decoration-line: underline;
  text-decoration-style: wavy;
  text-decoration-color: green;
}

.spelling-error {
  text-decoration: underline; /* for backwards compatibility */
  text-decoration: underline wavy red;
}
.grammatical-error {
  text-decoration: underline; /* for backwards compatibility */
  text-decoration: underline wavy green;
}

<style>
  .family-name {text-decoration: underline;}
</style>
<p>
  <span class="vcard" lang="ja-latn">
    <span class="fn n">
      <u class="family-name">Son</u> <span class="given-name">Goku</span>
    </span>
  </span>
   is the main protagonist in 
  <span class="vcard" lang="ja-latn">
    <span class="fn n">
      <span class="given-name">Akira</span> <u class="family-name">Toriyama</u>
    </span>
  </span>’s <i lang="ja-latn">manga</i> “Dragon Ball”.
</p>

.family-name {
  text-decoration: none;
  text-transform: uppercase;
}

The return of the u element originally appeared on HTML5 Doctor on October 25, 2011.

To offer a quick recap, hgroup was removed from the W3C specification only (not the WHATWG spec) by Hixie at the request of Steve Faulkner. The co-chairs requested the issue be reverted following multiple requests from the likes of Tab and Tantek. The current status at the time of writing is that hgroup is in the spec.

It seems that the future of hgroup will be decided during the HTML5 spec last call review which is expected to start on or around May 22nd 2011.

One of the main reasons for this element being removed was because some people felt that it was only in the spec was to keep the outline algorithm happy and that it didn’t really offer much else in the way of semantics. It has also been suggested that people were still struggling to understand how to implement it correctly. If, however, you need your memory jogging then we suggest reading our post on hgroup from last year.

Far be it from us to get involved in the political wrangling (and knob waving) of the W3C, therefore when news of this broke we doctors fired a few emails between each other discussing what was going on and what we thought should be the next logical step. The outcome from these emails showed that there was no clear majority. Some of the doctors, myself included, thought that the element was a handy addition to the spec and should be something that we fought to keep. Others, like Bruce, have made no qualms about their dislike for this particular element.

Regardless, we decided to see if we could solve this issue by offering up alternative solutions. Below are a few of the suggestions (and issues) that came out of the conversation. We understand that some of these suggestions come with their own issues and the consequences maybe haven’t been fully thought through, but the aim of this is to start a conversion, not provide a final answer.

<article>
  <header>
    <hgroup>
      <h1>Title goes here</h1>
      <h2>Subtitle of article</h2>
    </hgroup>
    <p><time datetime="2010-03-20">20th March, 2010</time></p>
  </header>                
  <p>Lorem Ipsum dolor set amet...</p>
</article>

Subtitle within header

<article>
  <header>
    <h1>Title</h1>
    <p>subtitle</p>
  </header>
  <p>Lorem Ipsum dolor set amet...</p>
</article>

The method suggested above is probably the closest example to what we currently have with regards to hgroup. Within this code example we have an heading level and p tag within the header element.

Although this might seem fairly straight forward, it does become more complicated if we have further elements within the header; additional p tags, spans etc.

Highest ranking heading takes precedence

<article>
  <header>
    <h4>Intro subtitle</h1>
    <h1>Title goes here</h1>
    <h3>by John Smith</h3>
    <p><time datetime="2010-03-20">20th March, 2010</time></p>
    <nav>
      <h2>Chapters</h2>
      <ul>...</ul>
    </nav>
  </header>                
  <p>Lorem Ipsum dolor set amet...</p>
</article>

Taking the previous example a bit further, here we have multiple headings within header and the machine could recognise that the h1 is the highest ranking and should be used in the outline. Other headings are excluded, with the exception of the h2 within nav as it is a sectioning content element and therefore still affects outline.

This allows the developer to have multiple subtitles of varying importance without affecting the outline. The drawback of this is the use of headings isn’t very intuitive when lower ranking headings can appear anywhere within header. Thankfully we still have ideas for other alternatives.

Span subtitle within header

<article>
  <header>
    <h1>Title <span>Subtitle</span></h1>
  </header>
  <p>Lorem Ipsum dolor set amet...</p>
</article>

This next technique is probably similar to something that you might have used before when coding up a page in HTML4, providing something of a natural progression, paving the cowpaths if you will. As the span is within the heading element it makes it clear that it is associated with the heading.

Some of the doctors are not convinced this is the correct way to progress and therefore looked for another alternative.

Introducing the subtitle

<article>
  <header>
    <h1>Title <span subtitle>Subtitle</span></h1>
  </header>
  <p>Lorem Ipsum dolor set amet...</p>
</article>

This example is almost identical to the example provided above. The only difference here is that we’ve added a subtitle attribute to help assistive software make the connection between heading and subtitle. Again, some Doctors are not completely comfortable with nesting a subtitle within a heading element.

It was also suggested combining this example and the first to come up with a better outcome. Whereby a developer would include a heading and p tag, marked up with the subtitle attribute, within the header element.

For attribute within header

<article>
  <header>
    <h1 id="title">Title</h1>
    <p for="title">Subtitle</p>
  </header>
  <p>Lorem Ipsum dolor set amet...</p>
</article>

Now for something totally different. The above example borrows an idea from forms using the for attribute. in HTML5, a number of elements which were previously required to be within a form element can now be located anywhere on the page and associated with a form using a form attribute pointing at the id of its form owner. This example extends borrows the idea an applying it to use with another attribute and element.

In our example the p tag is owned by the heading element. The interesting thing with this method, along with the forms, is that the subtitle wouldn’t necessarily have to be nested within the header, as assistive technology would still be able to associated which heading it belonged too.

What’s next and your suggestions

Issue 164 on the W3C tracker offers some further suggestions to how hgroup could be removed, modified or otherwise changed. Some of those are similar or the same as those we’ve mentioned above but now you’ve seen our suggestions and perhaps perused those in issue 164, so why not let us know your suggestions below in the comments.

This is a fairly big issue and one that a lot of people are still obviously undecided about, so here is your chance to seize an opportunity because, you never know, your suggestion could become standard practice.

The hgroup hokey cokey originally appeared on HTML5 Doctor on May 6, 2011.

While they’re essential reading material for our job, the W3C specifications are not exactly George R. R. Martin-level reading material. To make matters worse, the often-dry text (written for implementors, not authors) and…colourful illustrations come wrapped in a design straight out of 1999. While the W3C homepage got some lovin’ in 2009 from the dynamic duo of Happy Cog and Airbag Industries, the actual specifications are still only slightly above the baseline of browser defaults. So what’s a caring developer to do?

Ben Schwarz, a developer in Melbourne, Australia, took matters into his own hands with a userscript to give W3C specs some readability. Around the same time Mike™ Smith — the W3C team contact for HTML Working Group amongst other things — was looking for CSS help for HTML5: The Markup Language Reference, his cut-down reference version of the HTML5 spec. I was able to introduce Mike™ and Ben, and the result was HTML5 Edition for Web Authors. But this was only the start.

Ben then got on the WHATWG IRC channel:

Within 10 minutes of joining the WHATWG IRC channel Ian Hickson had granted me approval to continue with my own build of the spec, targeted for web developers.

After a lot of hard work, with input and encouragement from the web’s finest (including Dr Bruce), Ben has released HTML5 for Web Developers.

The focus of this specification is readability and ease of access. Unlike the full HTML specification, this “web developer edition” removes information that only browser vendors need know.

In addition to streamlining the content, it boasts all manner of freshly implemented buzzwords and technical trickery through the magicks of JavaScript and CSS:

• find-as-you-type search (type “/”)
• offline access
• alternate styles for mobile devices
• technical references pulled inline
• beautiful typography
• …and design

It’s been well received, with more than 20,000 uniques in the first 24 hours, and the Pied Piper of HTML5 remarking:

Enjoying the gorgeously readable presentation of http://developers.whatwg.org/ Nice work, @benschwarz.

The files to build HTML5 for Web Developers are on GitHub, so if you have any problems or suggestions add an issue. You can also fork the project and help out — I have!

The heavyweight specs

HTML5 — A vocabulary and associated APIs for HTML and XHTML by W3C

The HTML5 spec on the W3C site. It’s smaller than the other specs because several parts (including Microdata, Canvas 2D Context, and Web Messaging) have been turned into their own specifications.

I recommend this spec if you don’t follow HTML5 developments — e.g., if you’re not a reader of HTML5 Doctor. This is the specification being prepared for Last Call in May 2011, and it shouldn't change much from here on.

HTML — Living Standard by WHATWG

The HTML spec on the WHATWG site. It’s a superset of the HTML5 spec, including some things that the W3C has split into separate specs (see above). It also includes post-HTML5 features such as Web Video Text Tracks (WebVTT), but it doesn’t include non-HTML-specific specs like Web Storage, Web Sockets API, and Server-sent Events.

I recommend this spec if you are interested in HTML5 (and beyond) and wish to be actively involved. While it’s more liable to change (especially the new bits), it’s also likely to include improvements that haven’t made it into HTML5. It’s also what browser makers are looking at. You can also get to it quickly with the link http://whatwg.org/html.

Web Applications 1.0

This is everything the WHATWG is working on, including non-HTML-specific material (see above). It’s introduced with a photo of a kitchen sink ;)

While this is pretty much the same as HTML — Living Standard, I don’t recommend it because it doesn’t have the ability to hide implementor details. However you’ll need it if you’re interested in Web Storage, Web Sockets API, and Server-sent Events. You can get to it quickly with the link http://whatwg.org/C.

Cut-down versions specifically for authors (us)

HTML5: The Markup Language Reference

A quick reference for authors describing the syntax, structure, and semantics of HTML5. It's intended to be as concise and readable as possible. From the legend and self-styled W3C HTML5 jackass himself, Mike™ Smith, who also gets bonus points for the initialism “H:TML”.

I recommend this as a quick reference or cheat sheet to remind yourself of the essentials (well, in addition to the HTML5 Doctor glossary, of course ;-). It doesn’t have the depth of guidance or the examples in the other specs (or the implementor details), but it has info links to HTML5 for Web Developers, so you can easily get more detailed information.

HTML5 (Edition for Web Authors)

HTML5 for Web Authors was Mike™ and Ben’s first collaboration. It removes the implementation details intended for browser makers and adds some style, and it’s more in line with W3C’s HTML5 in that it doesn’t include microdata. For the time being, it’s been superseded by HTML5 for Web Developers.

I recommend this for JavaScripters, as it includes more API information than HTML5 for Web Developers. Currently it’s not as up-to-date as HTML5 for Web Developers, but I expect it to receive some love in the future.

HTML5 for Web Developers

HTML5 for Web Developers also removes the implementation details intended for browser makers, but includes some parts like microdata that have been cut from W3C’s HTML5 spec. I’m very impressed with the functionality and design, and I expect it to keep improving.

I recommend this for anyone wanting a beautiful, readable version of HTML5. With local storage, it’s also perfect for adding to an iPad home screen. As it’s on GitHub, it’s also the only spec where you can easily contribute to the design and functionality.

There’s a bunch of other related Editor’s drafts linked to in the HTML Working Group sidebar which may interest you. Lachlan Hunt’s HTML 5 Reference — a learning rather than reference-focused version of the HTML5 spec — is unfortunately currently out-of-date and on ice, so I don’t recommend it.

In Summary

I think these specs all have their place. Personally I’ve been mainly using the HTML — Living Standard version, but expect to use HTML5 for Web Developers a lot now too. The differences between these different versions of HTML5 (except for H:TML) can be broken down into two groups: the extra modules they include, and whether they include the option to show/hide implementor details — the HTML5 and HTML specs both do.

One fear John Foliot expressed is that you might accidentally end up using something that was highly likely to change. The WHATWG HTML and Web Applications specs, however, have annotations indicating the status of each item in the margin.

Handy!

I’ll leave the last words to Ben himself, who, a day after launching, said:

I'm thrilled to have it out, see good community support, and I hope that it becomes a reference for people to use every day

HTML5 for Web Developers originally appeared on HTML5 Doctor on February 25, 2011.

The facts

Ian Hickson, editor of the HTML5 specification, announced that HTML is the new HTML5, meaning that the WHATWG will drop the numeral "5" and just call their spec "HTML". HTML will be a "living standard", with a mixture of widely-implemented features like <canvas> or <video> and wildly experimental features like <device>. The W3C produces a spec called "HTML5". Ian Hickson (currently) edits both of them. They are different. The W3C creates a version of this technology which is under the W3C Royalty Free Patent Policy to give a better guarantee for developers against patents. This specification has the version number 5. (There's an interesting conversation to be had about the WHATWG, patent policy, and licensing, but that's not for today.)

TL;DR: nothing much changes (by Bruce Lawson)

So what does this mean? What changes for us developers? In practice: very little for most of us. Browsers process what they can process regardless of what mode they're in, what "version" of HTML is current, or what a document's DOCTYPE claims.

Take for example a document containing a <video> element, using WebM, Ogg, and MP4 <source> elements, with scripted controls using the media elements API, input type=range, and CSS3 opacity and transitions. With an HTML2 (yes, HTML2!) DOCTYPE, it's a fine example of HTML2 video.

If you're using a modern browser, everything will work fine. Your browser knows how to show those HTML5 goodies, so it does, regardless of what the DOCTYPE claims. What would be the point of a browser looking up what elements are part of HTML2 and refusing to show the video since <video> isn't part of that list? Such switching logic would take longer to process, delaying rendering for no practical benefit at all.

The only function of a DOCTYPE is to keep the browser out of Quirks Mode. The HTML5 DOCTYPE <!DOCTYPE HTML> is the shortest string that does this reliably. And note that there's no version number on that.

If version-less HTML surprises you, it shouldn't. It's what CSS has used all along. We happily use some CSS 3 modules without vendor prefixes (border-radius, for example) while we avoid some CSS 2 features because they have no support. So the version number has no practical use and we don't sweat it at all.

Here's an extract from a 2008 interview by xhtml.com with Bert Bos, who co-created CSS with Håkon Wium Lie (one of the core WHATWG members):

xhtml.com: I suspect many people haven't noticed that CSS has no version identifier….What drove the original decision not to include a version identifier and how has this affected the evolution of the CSS spec?

Bos: The working group has recognized since a long time that version numbers for document formats (as opposed to software) are a fallacy. HTML has version numbers (inside the DOCTYPE), but implementations either ignore them or use them for something else ("quirksmode").

Formats may evolve and be extended, as HTML and CSS are, but implementations won't provide different parsers for the different versions. They only implement the current version. The new version better be backwards compatible, or disaster will ensue. You might think that putting in a version number will cause old implementations to refuse documents that are too new, but it doesn't. None of the browsers written in the days of HTML2 will refuse to handle an HTML4 DOCTYPE. And none of the current HTML4 browsers will refuse an HTML5 document once HTML5 becomes a standard. No browser wants to admit it can't understand something and users don't want to use new features if that causes the whole file to fail.

The basic problem is that old and new software and old and new content have to coexist. It isn't possible to pick a day and switch all content and all software in the world over to the new version. And on the Web, some software, and especially some content, have very long life spans.

Sounds familiar, doesn't it?

(It's not the whole story. As I've mentioned above, all browsers use DOCTYPE to switch between parsing modes. Quirks mode is triggered by a line in the HTML, but it doesn't alter HTML parsing — it switches CSS parsing between IE5's broken box model or the W3C box model. Internet Explorer also has its compatibility mode which allows IE to mimic old, buggy versions. Note that these are switches to trigger buggy implementations; they are not switches between implementations of different versions of CSS or HTML. I may be splitting semantic hairs here.)

So HTML versioning will be the same as CSS versioning. With CSS, as it's only styling and not content or functionality, it doesn't matter much if something fails silently. With HTML5, we don't have vendor prefixes like CSS does, but most (if not all) new features can be feature-detected and poly-filled with JavaScript. It might not be beautiful, but it's the way of the world, and version numbers won't change that.

Ultimately, the presence or absence of a version number is less important than the fact that we have a spec that extends HTML without breaking backwards compatibility. That's what I celebrate in my Geek Song Living Standard.

Versioning isn't for browsers. It's for authors. (By John Foliot)

The main issue, as I see it, is that W3C Standards ("Recommendations" in their parlance) are not "snapshots". They're engravings, which implies a whole other level of stability and commitment. Engravings, for example, are used to print our paper currency.

The last standardized commit to HTML was over a decade ago with HTML 4.01 (Dec., 1999) (and/or the XML serialization of XHTML in January 2000, revised 1 August 2002), and HTML5 (the markup language), once finalized, will likely continue to be the benchmark a decade from now. While most would concede that HTML 4.01/XHTML 1.1 are somewhat dated today, you could (if you wanted) continue to build a site using <frames>, and it would work, and all user agents would know what to do with that code. Team members could work on that code in a shared environment, using different types of editing tools (including WYSIWYG tools). That work could span cultures and geographies as the specification has been translated into numerous world languages and teaching curricula. It is that kind of permanence and stability that comes with an actual Standard.

Just look at <hgroup>. Where are we with that today? Next week? April 2011? Who knows? (I sort of know. There's a bug filed, and it will likely be escalated to an actual issue in the Last Call process. <hgroup>'s future is under debate at this time, but with no firm timeline. The point is, you need to be on top of this stuff continuously, a task that many larger groups simply do not have the time or resources to do.) Then there is the accessibility of <canvas> and <video> — points I don't need to belabor, but issues that remain non-trivial today. Much of the current new "goodness" in the Draft HTML5 Specification has very little browser support. Look at the lack of complete support for Web Forms or many of the other newly introduced elements. It's gotten so bad that some of the less-informed think that the solution today is that all of the browsers should just move to WebKit and the problems will be solved — a suggestion so far-removed from any kind of reality as to be laughable. The answer is not to move to one rendering engine for stability, but rather for all to agree on one firm specification that works across all browsers.

My larger objection is around perception of the spec: developers who think that just because it's spec'ed at WHATWG this week that it's good to go, bring it on, to heck with permanence and legacy! It's a continued "fix-it-in-the-mix" attitude far-removed from the real world of large corporations and government. In the contest to be cool and cutting-edge, some developers forget that there is a world of commerce and actual Just-Like-Mom users out there who think that the latest advancement of the internet is Farmville on their cell phone.

I think the recent release of Drupal 7 is a great example. After nearly three years of intense community collaboration by nearly a thousand contributors, the latest version of this high-profile Open Source CMS was launched simultaneously with numerous plug-in modules re-factored for this next-generation build. Standards conformance was a huge driver for this version (as was accessibility support), so this large group of developers required an extremely stable benchmark to work towards. They couldn't rely on spec that changes monthly. Nobody wants to go back and re-write code they shipped four months ago simply because the current Draft Specification has changed the way things are done. Thus, the bulk of Drupal 7 sites I've seen to date (including those with custom themes) proudly sport the following under the hood:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN"
  "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">

WHATWG serves a useful function, no doubt. Like the Fashion Houses of Paris, New York and London, they create and explore and push the boundaries. But they also often remain far-removed from the world of F&F Clothing at Tesco — Tesco by the way being an "Official Sponsor of London Fashion Week". I truly believe that the web community needs to be reminded of this fact. An evolving spec serves the needs of browser vendors, but it is no friend to many commercial developers as it hurts larger entities who need to share authoring responsibilities.

Like that paper currency made from those engravings, I want to be sure I can take it to the bank.

About John Foliot:

John Foliot is a Web Accessibility Specialist with over a decade of experience in that field. He manages the Online Accessibility Program at Stanford University, and is a co-chair of the W3C's HTML5 Accessibility Task Force, where he is focused on accessibility of the new media elements. When not ranting on the web about web accessibility and web standards, he enjoys riding his motorcycle, listening to and collecting Blues music, and sampling fine Single Malts with fellow geek friends. You can follow him on twitter at @johnfoliot.

In summary

We've given two opposing views on this matter, and now we want to hear your thoughts. Are you for or against a living HTML standard?

HTML as a Living Standard — For and Against originally appeared on HTML5 Doctor on February 8, 2011.

<details>
<summary>More information</summary>
<p>Here is the source data that is discussed in the article ... </p>
</details>

This is designed to produce an “expando” box that is closed by default (but can be open by default using the boolean open attribute), only displaying the text specified by the summary as a control. Activating that control opens the whole details element; re-activating closes it again. If no summary text is present, the browser defaults to the rubric “details”. (Added 4 Feb 10:) In browsers that support details, this behaviour does not depend on author scripting, and should work even if JavaScript is disabled or not present.

figcaption lives inside the figure:

<figure>
<img ... > (or video, table etc)
<figcaption>A rabid unicorn goring a fairy.</figcaption>
</figure>

If you want some history, continue reading. Otherwise, bye bye!

Previously, the legend element was specified to do the job of both. Unfortunately, every browser had parsing problems re-using it outside forms. Similar problems were encountered attempting to re-use the caption element outside tables. At Jeremy Keith’s suggestion, the spec then re-used dd and dt, but that breaks too.

Now, two new elements are minted. (I quite fancied one new element – rubric for both, but it’s a pretty esoteric word.)

One of the objections to details, as described by Shelley Powers in her bug to remove it is

the use of JavaScript for the purpose of expanding or collapsing a section is both well-defined and common among web applications. More importantly, following the concept of progressive enhancement, these types of expanding sections are expanded by default if script is turned off. To have a section that is dynamic but not controlled by script is going to cause confusion, particularly among people who turn scripting off and are assuming that there are no “expando” sections in the web page.

In fact, I don’t see how this element will make developing web applications that much simpler. This type of functionality is trivial with JS.

My counter-argument was that an expanding/ collapsing area on the page is a very common requirement. I’ve seen sites pull in a whole JavaScript library just to accomplish this (presumably as the developer was unfamiliar with JS), which bloats the page size for the user. I’ve seen pages where the “details” information is set to display:none by default, and the user cannot expand the information without JS, thereby making the contents inaccessible if JS is not present.

Reinstating this element would be advantageous to developers, who wouldn’t need to learn JS to accomplish a common task; advantageous to users who would get an accessibility bonus from having this behaviour natively in the browser.

While I like to think that the irrefutable logic of my argument, coupled with the tear-jerking rhetorical flourishes in my prose captured both the heart and the head of the editor, I suspect what persuaded him was Apple’s Maciej Stachowiak saying that “the webkit community” were interested in implementing details once the spec was nailed down. Implementation wins the day.

Hello, summary and figcaption elements originally appeared on HTML5 Doctor on February 1, 2010.

When I wrote the previous version of this article a few months ago, I knew, as I’m sure many of you also knew, that this element in particular would be subject to change as the HTML 5 spec neared it’s completion. The problem was simple, the footer element just didn’t feel 'complete', it just didn’t offer the same flexibility as other elements. Now that’s changed.

In summary, the content model for the footer element has been changed to allow sectioning content like header or like nav. In fact it now works in very much the same way as the header element. However, it’s important to note that footer isn’t sectioning content and doesn’t introduce a new section.

If you’ve been working on a site and have incorporated a wonderful new footer with everything that it now allows please feel free to post a link in the comments to show other readers just what you can get away with.

Below is an updated copy of the original article.

Old Article

For some time now we’ve become accustomed to seeing <div id="footer"> at the bottom of web pages but with the introduction of HTML 5 it’s time to say goodbye. With the addition of the new <footer> element we now have more scope and flexibility.

According to the spec

The footer element represents a footer for its nearest ancestor sectioning content or sectioning root element. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like.

Lets get started

Before we get stuck into dissecting the new element, let’s lay the foundations for the article and cover the basics. As we’ve already mentioned above, most people would have laid out the footer as follows

<div id="footer">
  <ul>
     <li>copyright</li>
     <li>sitemap</li>
     <li>contact</li>
     <li>to top</li>
  </ul>
<div>

However with the creation of HTML5 this is no longer the case. As you may already know, there is now no longer the need for the <div> element for many elements. In our case, when referring to the footer, the appropriate markup would be <footer>

<footer>
  <ul>
     <li>copyright</li>
     <li>sitemap</li>
     <li>contact</li>
     <li>to top</li>
  </ul>
</footer>

As I mentioned in the first paragraph, originally the <footer> element was only utilised once within our pages but with the introduction of the new element, this no longer needs to be the case. The <footer> element can now be used multiple times and to display all the extra information.

Using the footer element

An important point to note is that you are not restricted to use one <footer> element per site, you can use multiple footers, each of which will then become the <footer> for that section of the document. You could therefore have a <footer> for a <section> or an <article>.

Section

<section>
   Section content appears here.
   <footer>
   Footer information for section.
   </footer>
</section>

Article

<article>
   Article content appears here.
   <footer>
   Footer information for article.
   </footer>
</article>

To see an example of the <footer> within an article/section look no further than this very page. Scroll down beyond the article and you will notice the light grey text section, which falls directly after the “further reading”. This grey text section which gives information about trackbacks, responses, tags and categories is infact using the footer element.

Footer

We’ve already outlined what the new footer can look like above.

Other Thoughts

I was initially thrown off-course by the presentational name of the element; my use here isn’t at the bottom of the page, or even at the bottom of the article, but it certainly seems to fit the bill – it’s information about its section, containing author name, links to related documents (comments) and the like. There’s no reason that you can’t have more than one footer on page; the spec’s description says “the footer element represents a footer for the section it applies to” and a page may have any number of sections. The spec also says “Footers don’t necessarily have to appear at the end of a section, though they usually do.”

Bruce Lawson – http://www.brucelawson.co.uk/2009/marking-up-a-blog-with-html-5-part-2/

Conclusion

The footer element offers the chance to define web pages giving them the correct semantic mark-up that they deserve but it’s vital to use these new found tags as they were intended for. Let’s not get carried away and misuse this tag like we have done with tables and divs.

Futher reading

• http://www.whatwg.org/specs/web-apps/current-work/#the-footer-element

The Footer Element Update originally appeared on HTML5 Doctor on September 29, 2009.

Clarification over section and article

The spec has been clarified to help authors correctly choose between when to use section and when to use article, and Bruce’s section post has also been updated.

footer now works like header

This was a big one and causing confusing to people coming to HTML5 for the first time. Originally you couldn’t include a nav element inside a footer, or a section.

Now the spec has been changed to match the header element.

details and figure saved

Instead of using legend, which didn’t work, Jeremy suggested (although slightly tongue in cheek) to use dt for the title and dd for the body. Ian Hickson agreed, and it’s in

Example:

<figure>
 <dd><video src="ex-b.mov"></video>
 <dt>Exhibit B. The <cite>Rough Copy</cite> trailer.
</figure>

aside has better examples

The documentation has been updated to specify better examples of how the aside element can be used.

Better examples help us authors understand how it can be used.

Dropped Elements

The following elements have been dropped from the HTML5 spec (though bb and datagrid were some time ago, and datagrid has been postponed rather than dropped entirely):

• dialog
• bb
• datagrid

Ch-ch-changes

We’ll be posting in more detail about some of these changes, and as further changes come out of the editing process we’ll no doubt keep you all up to date, either via our Twitter account (which you should follow) or feel free to let us know too!

September HTML5 spec changes originally appeared on HTML5 Doctor on September 17, 2009.