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