Re: Draft WebPlatform.org Blog Post on HTML5 CR

No warning to plan parties... How sad that wasn't thought of.

Awesome that it is finally CR though.

-Garbee

On 12/17/2012 6:20 PM, Doug Schepers wrote:
> 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:44:48 UTC