← Back to home

How to read web specs Part II – Or: The spec’s lifecycle


Intermezzo: A spec’s lifecycle

The process of becoming part of the Web Platform usually goes like this:


You have an idea for an API and want to turn it into something real. The first step would be to draft an “explainer”. It’s an informal document describing the goal of your API and a rough outline of what the API would look like. You can then use that explainer to start a discussion in the [Web Incubation Community Group (WICG)][WICG]. You can iterate on both the responsibilities and design of the API with other web developers and browser engineer. If at least 2 browser vendors express interest in the API, you can move forward!

Editor’s draft (ED)

At this point, your API turned into a real spec. Usually, you have a public repository on your GitHub with both the explainer and the spec document. And since [Tab Atkins] published [Bikeshed], anyone can write a spec!

Bikeshed is a pre-processor for spec documents, turning a source document (containing only the actual spec content, plus several shorthands for linking to terms and other things) into a final spec document, with appropriate boilerplate, bibliography, indexes, etc all filled in. It's currently used on nearly all specs in the CSSWG, as well as various specs in the FXTF, SVGWG, WebAppSecurity, WHATWG, and elsewhere!

TODO: When does it move on?

First Public Working Draft (FPWD)


Working Draft (WD)


Candidate Recommendataion (CR)


Draft Community Group Report (DCGR)




A flowchart for the lifecycle of a spec