- From: Doug Schepers <schepers@w3.org>
- Date: Mon, 17 Dec 2012 18:20:29 -0500
- To: "public-webplatform@w3.org" <public-webplatform@w3.org>
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 Thanks- -Doug [[ 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. Nightlies 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. Extensions 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 release. 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