about:csswg
An Inside View of the CSS Working Group at W3C
This series of posts is about how the CSS Working Group operates in reality.
Spec Process
The following is the W3C Recommendation Track. Officially it has six phases; however in the CSSWG, we view the process as having only three phases, since the rest are really just formal transitions:
- Working Draft (WD)
This is the design phase of a W3C spec. The WG iterates the spec in response to internal and external feedback.
The first official Working Draft is designated the “First Public Working Draft” (FPWD). In the CSSWG, publishing FPWD indicates that the Working Group as a whole has agreed to work on the module, roughly as scoped out and proposed in the editor's draft.
- Transition: Last Call Working Draft (LCWD)
The transition to the next stage is the “Last Call Working Draft” (LCWD) phase. The CSSWG transitions Working Drafts once we have resolved all known issues, and can make no further progress without feedback from building tests and implementations.
LCWD sets a deadline for reporting any outstanding issues, and requires the WG to specially track and address incoming feedback. The comment-tracking document is the Disposition of Comments (DoC). It is submitted along with an updated draft for the Director's approval.
- Candidate Recommendation (CR)
This is the testing phase of a W3C spec. Notably, this phase is about using tests and implementations to test the specification: it is not about testing the implementations.
Demonstration of two correct, independent implementations of each feature is required to exit CR, so in this phase the WG builds a test suite and generates implementation reports.
- Transition: Proposed Recommendation (PR)
The transition to the next stage is “Proposed Recommendation” (PR). During this phase the W3C Advisory Committee must approve the transition to REC.
- Recommendation (REC)
This is the completed state of a W3C spec and represents a maintainance phase. At this point the WG only maintains an errata document and occasionally publishes an updated edition that incorporates the errata back into the spec.
Theoretically, a spec moves linearly forward on the W3C Rec Track; however in the CSS WG's experience, specs often move backwards in response to feedback as well as forwards. We are getting better at managing specs along this track as we've become more stringent about specs that we push to CR (but there are also some holes in the W3C Process that unnecessarily force specs backwards).
Back in 2007, I broke down the development stages of a CSS WG spec. This breakdown is finer and more subjective than that of the W3C Rec Track, but shows how a spec develops and stabilizes over time. (As with the W3C Rec Track, specs can move backward as well as forward in response to feedback.) What types of changes are handled at the WG vs editor level depends a lot on the spec's maturity on this scale:
- Exploring (pre-FPWD, early WD)
- In this stage the spec is often incomplete, possibly changing greatly between drafts, and possibly including many features that will be dropped as the spec matures. The editor will report on major changes and new features to the WG, and the WG will give guidance and suggestions to the editor or officially resolve on design approaches or scope for the module. Otherwise the editor incorporates any and all non-disputed feedback on his own. An official FPWD is published during this stage (which, in the CSS WG, is a signal that the WG as a whole is willing to adopt this module), and usually several more Working Drafts as well.
- Revising (mid-WD)
- At this point the module is mostly complete and the scope of its
functionality is well-defined, but the spec still needs several
cycles of publishing, review, and revision to uncover issues and
resolve them. In this stage, while significant design-level changes
are pushed to the WG for review, the editor will handle other
non-controversial issues.
By the end of this stage, the WG will have made any decisions on what features to cut or keep for this level of the module and the module's feature set will be frozen in preparation for CR.
- Refining (late WD, LCWD)
- At this point the spec is pretty stable and almost ready for CR, but may still need some tightly-scoped changes e.g. handling last-call comments, or general minor polishing. All substantive issues, aside from obvious error-fixes and clarifications, are pushed to the WG for official resolution. This stage corresponds to LCWD, but may also include a pre-LC Working Draft publication (to shake out remaining issues before initiating the formal LC process: this helps avoid multiple LCs).
- Testing (early CR)
- At this point the WG believes the specification to be complete and precise enough to be implemented, and that no further progress can be made without feedback from implementation experience. By transitioning it into the CR status the WG has issued a call for implementations and test cases. In this stage all non-editorial changes must be formally approved by the WG, and the section numbers are locked down.
- Stable (late CR)
- At this point the WG has enough testing and implementation experience that it considers the spec stable and dependable. Issue reports are infrequent and mostly minor; implementation coverage of the spec is complete; and any tests that fail to pass two implementations are well-understood to be implementation bugs that will be fixed. This stage is indicated by inclusion in the latest CSS Snapshot.
- Completed (PR, REC)
- At this point the test suite and implementation reports are all done, the specification has successfully exited CR, and, although the editors are responsible for maintaining errata, no further changes are expected. Non-essential editorial modifications are discouraged, and any potentially substantive changes must be approved by the WG.