How to Write a Standard: An Inside View of the CSS Working Group at W3C
The Web Dev Zone is brought to you in partnership with Mendix. Discover how IT departments looking for ways to keep up with demand for business apps has caused a new breed of developers to surface - the Rapid Application Developer.
In particular, I noticed something about the wording of Steve Faulkner's original revert request:
the editor of the HTML5 specification has made a change to the specification that is not supported for good reasons (see below, source: http://willyou.typewith.me/p/9Zl7I2dOKs)
I therefore request a revert of this change http://html5.org/r/6783, so that it can be further discussed and decided within the consensus based HTML WG process.
Okay, everybody likes consensus, especially about standards. But the once-upon-a-time student of decision theory and commitment devices in me perks up skeptically at (even implicit) accusations of unilateralism.
Lucky for me, an Invited Expert from the CSS Working Group at W3C has already posted a thorough treatment of how the CSS group works. The inside-view really gives a better feel for how people really act in the CSS group -- more than, for example, the official charter and process document of the HTML Working Group (which are very top-down, as presumably documents of this sort must be).
CSS isn't HTML, of course. But CSS is now being developed in modules, rather than tangled, monolithic versions; and one of the differences between W3C and WHATWG (the 'other' HTML5 standards group) is that W3C is maintaining the kinda-versioned 'HTML5' designation, while WHATWG now treats HTML as a 'living standard' (complete with an exacting list of differences between the W3C and WHATWG specs). So versioning is a bit of a thorny point in both HTML(5) and CSS, and the issue of versioning must deeply affect any standards-regarding decision-making process.
The full site goes into a lot of gritty details -- interesting for anyone interested in decision-making at this level, but especially for anyone involved in defining new web standards.
But most of us aren't defining new web standards. So, for the rest of us, here's an outline of how the CSS Working Group does its thing, in tl;dr form:
- People and Roles:
- module editors (in charge of each module)
- CSS WG members (inner group of discussants)
- www-style contributors (all other discussants)
- mailing lists (technical discussions; high volume; members follow closely)
- telecons (1hr, once/wk; chair presides, scribe takes minutes)
- face-to-face meetings (3 full workdays, 3-4 times a year; half in USA, half split between Europe and Asia; one meeting takes place along with other W3C groups; addresses deepest/hardest/complexest issues)
- IRC (side-discussions during official telecons; unofficial chats)
- internal mailing list (mostly just planning meetings and other administrative tasks; any technical discussion is immediately moved to the public www-style list)
- www.w3.org (homepage with specs and blog)
- dev.w3.org (editor's draft specs, with revision history)
- wiki.csswg.org (lots of stuff, technical and administrative; general-purpose, like any good wiki)
- test.csswg.org (subdomain=giveaway)
- Making Decisions (usually somewhat informal; for this one read the full treatment)
- Modularization (first formulated during 2007 CSS-WG meeting in Beijing; page includes history and rationale)
- Spec Process:
- working draft (with numbered iterations, until Last Call Working Draft)
- candidate recommendation (calls for implementations; this usually means lots of implementations already exist)
- recommendation (=finished; arrived at only after two correct independent implementations exist)
- Sources of Innovation (full post discusses three different sources for CSS3 Backgrounds and Borders)
Makes sense to me.