A Touch of Class



An Inside View of the CSS Working Group at W3C

This series of posts is about how the CSS Working Group operates in reality.

Making Decisions

As per the W3C Process, the CSS WG makes decisions by consensus. Consensus in the CSS WG is generally evaluated more informally than the W3C's official definition. We'll discuss an issue until everyone seems to be on the same page, and then the chairs will ask for objections before directing the scribe to mark the issue officially RESOLVED. Although sometimes details or a final confirmation will be deferred to email, official CSS WG resolutions are only those made at meetings and recorded in the minutes.

In cases where a consensus is not clear, the chairs will take a straw poll. If there is an overwhelming majority in favor of one option and those dissenting are willing to live with that option, it will be taken as the CSS WG's consensus and a resolution issued accordingly. In some cases where there is a clear lack of consensus, the chairs will either defer the issue until later or (if appropriate) default to no change. In case the CSS WG cannot come to a consensus on an issue, the W3C Process outlines procedures for a Formal Vote. The CSS WG has, thus far, never had to use this fallback.

Maintaining existing standards requires that the key stakeholders (the people who implement them and the existing content on the Web) are able to align with any changes. For mature specs we require even minor changes to be proposed to and formally approved by the whole group. This ensures that everyone is on board with the changes and has a chance to point out potential pitfalls and regressions.

On the other hand, drawing up new specs requires lots of brainstorming and revision, and therefore the ability to make lots of changes quickly in response to feedback on the design and details of the spec. Passing every substantive change through the WG resolution process would be restrictive and inefficient.

In the CSS WG, editors are not merely responsible for editorial tasks and executing the WG's decisions: a certain amount of authority is delegated to the module editor so that he can function as a front-line responder to feedback and realize a coherent technical and editorial vision for the module. Unlike other WGs, however, the editor is not a dictator who is occasionally overridden by an oversight committee. Decision-making authority rests with the CSS WG as a whole. Significant and/or controversial changes must be approved by WG consensus. What is “significant” varies by the maturity of the module: for younger specs, the CSS WG skews more towards allowing changes at the editors’ discretion.

There is no special process for “escalating” an issue to the CSS WG. WG decisions are in fact the default process, and an editor's decision is really an exception to the rule (albeit a common one). This exception is made when the change is:

In all other cases, the editor is expected to bring the issue to the WG's attention at a meeting, possibly with a proposal for how they feel the issue should be resolved and/or a summary of the feedback received.

CSS WG review is not just about oversight—it is also used as a resource for solving issues and making progress. Editors can bring issues to the WG when they are unsure about how to resolve them, or otherwise feel they would benefit from others’ experience or perspectives. Since the CSS WG is the highest authority on CSS, bringing an issue to the WG is a way to definitively resolve an issue when discussion on the mailing list is not making progress.

Our decision-making process allows rapid progress on specs while ensuring that all members of the WG can be aware of what's going on in all of CSS and have the opportunity to review and comment. It focuses members’ attention and expertise on the issues, ensures that all implementors are on board with the latest developments in CSS, avoids tedious formal appeals processes, and allows the CSS WG to ensure consistency across all the modules of CSS and over time.

Next up: CSS WG — Modularization