Draft WebPlatform.org Blog Post on HTML5 CR

Hi, folks-

As you may know, HTML5 was published today as a Candidate Recommendation 
at W3C.

W3C's MarComm team has already done a good job with the official W3C 
communications about HTML5's CR release [1]; it covers it well, explains 
everything it needs to explain, answers open questions, and feeds the 
story to the press in a easily digestible way. As part of W3C DevRel, 
I'd like to make standards be more relevant and relatable to the average 
web developer or designer.

It seems advantageous for WebPlatform.org to also talk more about 
progress on the Open Web Platform, including notable implementations, 
browser releases, and standardization progress.

I decided to take a rather different approach than W3C's formal 
communications, to explain HTML5 CR to developers in a way that isn't 
already covered. I framed it in terms of something they can relate to 
better: browser release cycles (and software releases in general). I 
hope this is a good complement to what W3C's MarComm has done.

So, as I mentioned last week, I plan to do 2 things: write a blog post 
[2] (or appended below for those that don't have access to the blog), 
and make an HTML5 page [3] on Web Platform Docs.

By laying out this blog post the way I've done it, it gives us the 
chance to build on that metaphor (spec as software) in future posts.

I believe that adding more kindling to the bonfire we're already blazing 
today will add little extra light and heat, so I plan to wait a couple 
days, maybe until Wednesday, to post this blog entry, to throw another 
log on the fire as it's dwindling.

Chris and I are still working on the HTML5 page [3] for Web Platform 
Docs, but it will be ready in time for this blog post.

So, if you have suggestions about this blog post, or about what we can 
do for HTML5 on WPD, please let me know.

I've already gotten some feedback that CR is more like an RC (release 
candidate) than RTM (release to market). I'd like to hear from different 
browser vendors on their terminology and process, so I get it right...

[1] http://www.w3.org/2012/12/html5-cr
[2] http://blog.webplatform.org/?p=67 (admins only)
[3] http://docs.webplatform.org/wiki/html/html5


HTML5 is Going Gold

On Monday, W3C published the HTML5 specification as a “Candidate 
Recommendation” (CR). What does that mean to Web developers and 
designers? How does that affect your daily job? And how does this relate 
to Web Platform Docs?

Standardization is not something most Web developers and designers deal 
with directly, and many of you may not be clear on some of the details. 
But you are all familiar with software release cycles, so I’ll draw the 
analogy with browser releases (and really, it’s a pretty close match).

Going Gold

In browser release terms, for example, CR is the equivalent of a release 
candidate branch with feature freeze. That means that there’s still 
plenty of work to do before the final release, but we’ve defined the set 
of features that’s in, and what’s out. It’s fair to say HTML5 is going 
gold (that is, CR is similar to RTM).

General Availability

The final major milestone is publication as “Recommendation” (Rec) 
status… if this were software, this would be the formal launch or public 
release, also known as General Availability (GA).

What work has left to be done between CR and Rec? Mostly testing. We 
need tests (lots and lots of tests) to make sure that all the features 
are defined clearly enough to be implemented consistently across “User 
Agents” (i.e., all the desktop and mobile browsers, authoring tools, 
bots, and anything that reads or writes HTML on behalf of the user). We 
also test to make sure that it is not only implementable, but actually 
implemented… in other words, before we say that the spec is ready to be 
considered a standard, there need to be at least two browsers (or more, 
preferably) that support each browser feature. Once we create all the 
tests that are needed, usually many tests for each feature and 
combination of features, we gather them into a test suite, and test all 
the various User Agents and record the results in an Implementation 
Report. This Implementation Report is the primary piece of evidence used 
to judge whether a spec is ready to be declared a standard… that is, 
ready to ship.

Like with a browser release candidate, there may be features that are 
pushed to the next release. In other words, they are dropped from the 
branch, but not the trunk.

Back on the Trunk

But just like with a browser release, the work is never done… there will 
always be bug reports and fixes, and sometimes even changes. W3C 
Recommendations are revised, through new editions, or even new versions.

Because development doesn’t stop with a “final” release. The Working 
Group keeps working on the master branch (or “trunk”): the main spec, 
with new features, some experimental, some solid and well-defined.

In this case, the next branch is the HTML 5.1 spec, which was also 
published Monday. Right now, it’s a “point-release” spec, because it 
doesn’t have enough new features to warrant a new major release… but as 
it develops over time, it might morph into HTML 6.


The equivalent of the nightly browser build is the Editor’s Draft (in 
fact, the HTML5 editors even call their Editor’s Draft’s “nightlies”). 
That’s where you go to find the next generation of possible features, to 
try out the ideas, and to comment. Some of the features will need only a 
little revision and polish, and some will be dropped completely, because 
they didn’t do what they were designed for, or because they introduced 
security holes, or any other reason that experimental work doesn’t make it.


The HTML WG, like the CSS and SVG WGs, is also experimenting with 
modular specs. You can think of these as browser extensions… developed 
on the side, smaller and more focused, easy to iterate and refine. And 
some of these features might be folded into the trunk. Some of the 
modules also published on Monday include Canvas 2D (aka, Canvas) and the 
new spec for the HTML <main> element. These are each on their own 
release cycles.

So, in a nutshell, that’s a portrait of a specification as a browser 

Web Platform Docs

So, how does this relate to WPD, and the Web Platform project in general?

Specific to HTML5, we’ve created a dedicated HTML5 page on WPD that 
breaks down the features of HTML5  into categories like new elements, 
attributes, and APIs, existing stuff, and things that are now obsolete. 
We also have tutorials that can help you get started.

But more generally, we recognize that all that status information is 
hard to keep track of, so we are doing our part to keep you informed.

On this blog, we will let you know about those milestones that we think 
you should be aware of, including opportunities to review specifications 
early, while there’s still a chance to change them. We’ll also do a 
roundup of progress in various specifications.

We’ll also be working with the organizers of Test the Web Forward, and 
we hope you will too. The best way for you to ensure the features you 
want get developed quickly and interoperably is to do something you 
already do: write and review tests. (And you should also review the 
specs, if you’re so inclined.)

Going forward, as WPD matures, we will reflect all this detailed 
information about browser support more systematically. We are working 
with PPK from QuirksMode.org and Alexis Deveria from CanIUse.com on 
plans to integrate their data . In addition to that, we will be 
integrating results from W3C’s own test suites and implementation 
reports, letting you drill right into the tests. We won’t leave you 
guessing about how we decide when and where and if something is 
supported… we’ll back it up with solid facts, because we know you need 
to make decisions as a professional.

This week, the Web just got a little better, a little more stable, and a 
little more powerful.

Received on Monday, 17 December 2012 23:20:44 UTC