A Touch of Class

fantasai
2007-05-23

Behind the Scenes: What is the CSS Working Group doing?

Lately there's been a lot of talk about the CSS Working Group and about how we're closed, out-of-date, slow, and/or dysfunctional. I'm acknowledging Andy Budd's post here and other comments. It's not very clear what we're working on or why it's taking so long, so I decided to write couple posts, from my perspective as a CSS Working Group Invited Expert, on where we are, why we're here, and where I think we should be going.

Disclaimer: This is my personal viewpoint and does not necessarily represent the perspective of anyone else.

First I'm going to answer a few questions that seem to be floating around.

What is the CSS Working Group doing these days? Why not a CSS2.2?

For those who think CSS2 was finished quickly and now CSS3 is taking forever... CSS2 wasn't finished. It was published as a W3C Recommendation because back then, a Recommendation was the same as a Candidate Recommendation is now and got even less scrutiny from experts like David Baron and implementors like Boris Zbarsky. So CSS2 will actually be finished when CSS2.1 is finished. It's not done yet.

The CSS Working Group is working on three things these days:

CSS2.1
Unless you're tracking every issue, it's hard to understand how much work has gone into CSS2.1. It's not just taking a "snapshot" of CSS support as of 2002: most of the work is going into fixing hundreds of loopholes, mistakes, and conflicts between the spec and implementations or the spec and itself. There's no immediate practical benefit to web authors, but the implementors need a super-precise spec in order to all aim at the same behavior. Minor cross-browser incompatibilities drive web designers nuts. Having a common goal for each of these will help implementors make those go away.
“CSS2.2”
We're not working on a CSS2.2 as such, but that's because CSS3 is modular. We're working instead on cutting down and/or refining features in earlier CSS3 drafts in order to get some CSS3 modules into a stable, implementable state. Selectors has already made it, CSS Namespaces is almost there, and believe it or not, CSS Backgrounds and Borders is pretty close.
CSS3
Some of the CSS3 modules out there are "concept albums": specs that are sketching out the future of CSS. Among these explorative specs are CSS Advanced Layout, the outdated CSS Generated Content, and the more recent CSS GCPM (a miscellaneous collection of print-oriented features).

Most of our focus as a group has been on CSS2.1. Progress on other drafts depends entirely on whether we have an interested editor who's putting in the time.

Drafts that have been pulled back from CR were pulled back due to problems in the CR. If a specification needs substantive changes, even minor ones, it has to be returned to working draft status. Selectors was pulled back for relatively minor changes; CSS2.1 was pulled back for lots of tiny to medium-size changes; and CSS3 Text was pulled back for a complete rewrite (see e.g. my comments from 2003).

Why is the CSS Working Group so slow? Wouldn't being more like the WHATWG speed it up?

It's mainly about time. The active CSS Working Group members all have very busy full-time jobs, many of them at the manager level. These members would love to spend more time on moving CSS forward, but due to their many other responsibilities, just can't. It's been argued by some that being a committee rather than a dictatorship is inefficient, but aside from CSS2.1 and other CR-level drafts where we need to make sure all the implementors are on board with any changes, the CSS WG only exercises loose oversight on a spec editor's work: ultimately the bottleneck is the total amount of time×skill spent banging at the keyboard.

(Notice that the WHATWG has an extraordinarily talented and knowledgeable spec-writer working more or less full time on the HTML5 spec, and the draft is still in the unfettered-development working draft stage.)

I have time and technical ability. How can I help?

Comment on our work
Our specs are open to public comment. Look them over and give us feedback. Tell us about our grammar mistakes and logical loopholes, or pros and cons about a particular feature's design and how to improve it. Send us examples we can add to better explain the prose, or suggestions for features that would really make your day (and make sure you explain the inspiring scenario that's giving you a headache right now). Most of us aren't web designers ourselves, so we need well thought-out comments from that perspective.
Help with the test suite
Each stable CSS spec has an associated test suite. The test suite serves several purposes: it helps implementors see their bugs and fix them; it helps spec writers see their bugs and fix them; and it lets the spec qualify for Recommendation once two implementations pass it. The CSS2.1 test suite needs many more tests to be complete. It also needs people to review each test and make sure it's still correct with respect to the updated specification. So if you're not up to writing new tests, point your favorite browser at the CSS2.1 Conformance Test Suite and see where it fails. If a test fails in more than one of Opera, Mozilla, or Safari and you're not sure the spec's prose is backing up the test's failure, send an email to public-css-testsuite@w3.org asking for it to be reviewed and I'll take a look.
Become an editor
While anyone can comment or contribute to the test suite, becoming an editor is not as simple. Writing good specs is a skill, just like programming is a skill. Even just reading specs and interpreting them correctly is a skill. If you have that down and feel you know CSS and its design principles inside-out, you can consider becoming an editor. If there's a spec that isn't moving and you really want to help push it forward, start by commenting. Review it as if you already are the junior editor, and the current editor is your senior co-editor. Post emails to www-style explaining what needs to be fixed and why with specific replacement text that will solve the problem. If you're good, and we feel we can give you responsibility for the spec without needing to look over your shoulder, we'll make you an invited expert and assign you to the spec. David Baron, Ian Hickson, and I all started out by commenting in www-style and from there became invited experts.

Why can't you Just Ship CSS2.1 and fix the problems later?

You can Just Ship software with bugs in it to put out a new stable release because it's versioned. The next version replaces the old. You can always fix the leftover bugs in the next version. CSS doesn't have versions. Any problems there are in the way CSS2.1 defines things can't be fixed in CSS3 except maybe by adding really confusing sets of switches. CSS3 cannot change anything in CSS2.1, it can only build on top of it.

CSS Working Group Myths

Next, I want to set the record straight on a few things:

Myth 1: The CSS Working Group doesn't invite feedback from the web community.

The W3C has had an open, archived mailing list dedicated to getting feedback on style sheets from the public since before there was a CSS Working Group. It's called www-style@w3.org and anyone can join, post, and participate in discussions as long as they agree to let the W3C archive their comments. We publish public drafts of our specs precisely so that we can get comments from web designers, implementors and random techies.

If you're posting a weblog entry about one of our specs, whether you're famous or not, chances are we won't see it. Post the URL to www-style, or at least private-message it to someone and ask them to post it for you. Don't be shy: we do want to hear your opinion, good or bad.

Myth 2: The CSS Working Group members want to be closed and insular.

The W3C standards development process has historically been somewhat closed: public mailing lists were available for discusssion, but decisions were made behind the scenes by committees of paying W3C members. From what Bert (our chair) has been saying over the years, there seem to be several reasons for this:

As Daniel Glazman would have one believe with his stories of confrontation at the table and smoky-backroom negotiations in the hallways back during the Netscape-Microsoft browser wars, reasons #2 and #3 were probably much more important in the past. Nowadays, the CSS Working Group makes almost all its decisions by consensus. Very few decisions have come to a vote. Very little confidential information is shared. We'd be happy to open up more of our records to the public, and we resolved at the last face-to-face meeting that we want to shift all our technical discussion to a public mailing list if we can just sort out the inevitable IPR issues.

I do believe the CSS Working Group can and should be more open, but the reason we're not more open is a lack of time and pressure to overcome the bureaucratic overhead and inertia, not a lack of desire to interact with the rest of the world.

Myth 3: Microsoft is holding back CSS standards development and/or doesn't care.

I have no idea what Microsoft Corporation's agenda is, but ever since they rejoined the CSS Working Group, the Internet Explorer team has been actively participating in the working group. Markus Mielke has been consistently pushing us to spell things out explicitly one way or the other rather than leave anything undefined, and most recently Paul Nelson, whose expertise is in internationalization and fonts, has volunteered to pick up some of the specs whose editors left the working group years ago. That's not the behavior of a group that wants to hold back standardization. Markus's team wanted to fix more bugs in IE7, but the release schedule didn't give them the chance to make many of the changes they wanted. The company as a whole may be trying to undermine the Web's openness, but the reps they send to the CSS Working Group genuinely believe in cooperating through the W3C and moving forward with web standards.

Continue: problems I see and how I think we should address them.

P.S. I don't have a trackback or commenting system, since this is static HTML. But css3.info has a copy, so you can talk back there.