Originally set up by Remy, the IRC channel is there for brief questions about all things HTML5. If one of the HTML5 Doctors is around, we can try to help you, or if you don’t have a question, you’re more than welcome to idle and talk with the H5D community.

For those who don’t know what IRC is, it’s a protocol for chat that’s been around almost as long as I have! No matter what OS you use, you should be able to find an IRC client to get connected. There are even web-based services like Freenode’s own web IRC and IRC Cloud, so you can jump on no matter where you are with nothing to install. The Mibbit wiki has an IRC tutorial to help get you using IRC, and Freenode hosts a guide to using the network.

When you’re ready, the channel can be found at #html5doctor on Freenode (irc.freenode.net). Once you’re connected and you’ve joined the channel, say hi and see who’s around. If no one is there, stick around, and maybe check out other channels on Freenode such as the WHATWG channel, #whatwg.

The only thing to keep in mind is that we HTML5 Doctors do this voluntarily with jobs and lives to run. We can’t be there 24/7. When we are available to answer questions, we’ll try to address whomever we can, and maybe another idling patient will be able to lend a hand.

For more extensive problems, or if you also don’t have time to hang around on IRC, check our article archive or drop us an email through Ask the HTML5 Doctor if you can’t find your answer there.

Drop on by, hang out, and feel free to talk all about HTML5 and the wonderful web.

And please, no medical questions!

HTML5 Doctor Drop-In Clinic originally appeared on HTML5 Doctor on February 16, 2012.

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.

I understand why someone might think that, but it’s wrong. 2022 was misinterpreted as the year HTML 5 would be ready. That’s wrong. HTML 5 is ready today.

In an interview by Tech Republic, for a techie audience, Ian Hickson, the editor of the HTML 5 working draft, was asked to give a timeline of the HTML 5 recommendation.

One date should have come out of that interview, but another, much further away did instead: 2022 – the date of the final proposed recommendation, which actually translates to:

require at least two browsers to completely pass [HTML 5 test suites]

Let’s put this in context of another spec that has taken a very long time: CSS 2.1.

CSS 2.1 is CSS that I’m certain you’re familiar with. I’m certain you use it day to day without any thought as to whether it’s a completed spec.

It’s been in development for over 10 years, and it’s only just become a candidate recommendation (23rd April 2009).

That said, it doesn’t have two browsers completely supporting it. Only Internet Explorer 8 supports the full CSS 2.1 spec.

Did that stop you from using CSS 2.1? I suspect not. Will that stop us from using HTML 5? It certainly shouldn’t. HTML 5 is available and ready to be used today.

What is the important HTML 5 date?

October 2009.

This October is the last call for the HTML 5 working draft.

That means, that issues with the spec, enhancements, bugs, anything, it all needs to be in and submitted and written in to the spec for October this year (it can go through reiterations, the this is the main deadline).

The WHATWG is completely open for anyone to contribute their ideas and suggestions.

You can sign up to the mailing lists, look through the backlog of mailing list. You can communicate directly using IRC and there’s even a complete log of all the IRC history. All available from http://whatwg.org.

2022, or when will HTML 5 be ready? originally appeared on HTML5 Doctor on July 21, 2009.