CSS3

This post was written by fantasai on 23-5-2007 on her weblog, she e-mailed us and asked us to put it up here for the greater public to enjoy and be able to comment.

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 a 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.

In my last post, I explained a little about what we’re doing and how we operate. In this post, I’ll cover the problems I think we have and how I think we should address them.

What needs to change

(Besides companies allocating more man hours to working on css specs. ;)

Problem 1: Lack of web designer perspective

In my opinion, the CSS Working Group has been too dominated by browser implementors and gives too little weight to what web designers really want. For most of my time on the working group, the only representation we had from the web design community was from AOL: from Kimberly Blessing and Kevin Lawver. When Andy Clarke joined the CSS Working Group as an Invited Expert last year, I was really excited: finally some more web designer perspective. But Andy and Kevin are both too busy to be regular participants,and when they are around, they’re not technical enough to really follow the discussions and understand the impact some silly sentence in the spec has on what web designers are trying to do. Therefore our decisions tend to get made from the implementors’ perspective, even when it goes against common sense. Bert and I try to represent common sense, since neither of us represents anything else, but if there’s an impasse between us and the implementors, we’ll get voted down. Very often the working group would seriously consider the position of the web design community if they knew it, but Bert and I cannot represent to them how important an issue is for web designers, and the web designers aren’t there to speak for themselves.

Recently the increased participation of Adobe (Steve Zilles), HP (Melinda Grant), and even Microsoft has helped a lot to balance the excessive bugwards-compatibility bias we had for several years, but we’re still not aligning our work with the needs of the web design community as well as we should. It’s not an easy problem to fix. We need more dialogue between the CSS Working Group and the web design community, but simply putting some web designers on the working group doesn’t make that happen.

Problem 2: Poor communication with the public

Ian Hickson and Anne van Kesteren keep saying that the CSSWG should be restructured like the new HTMLWG, where anyone who wants to can join, and are disgusted that we aren’t seriously considering it. I’m far from convinced that this is a good idea. Making the HTML Working Group actually work is going to be an exercise in herding lots of very opinionated cats. I’m optimistic that as the undisputed master of the HTML5 spec (and an ardent cat-lover), Ian Hickson can pull that off, but we don’t have anyone with comparable ability, commitment, and sense of direction for CSS, and it would also set us up with a single, hard-to-replace point of failure. Ian has made himself indispensable before; it doesn’t work so well when he gets busy doing something else.

Another model that’s often brought up is the WHATWG. But the WHATWG isn’t actually structured more openly than the CSSWG. Its structure is more closed: it’s the communication lines that are more open. Consider:

• The WHATWG has open participation for discussion, and a dictator-editor who writes the spec.
• The CSSWG has open participation for discussion, and a dictator-committee who writes the specs.

It’s not possible to “join” a dictator-editor, but it is possible for somebody to join a dictator-committee. Therefore technically, structurally, the CSSWG is more open. But practically, that’s not what makes the difference in how open the spec-writing process is. The WHATWG’s process is more open because the WHATWG’s dictator-editor has set up multiple communication channels for feedback and responds quickly to that feedback, both with messages to the mailing list and with instantly-public updated drafts. The CSSWG publishes only snapshot drafts, posts little to the www-style list, doesn’t respond readily to feedback, and often doesn’t even acknowledge that feedback until the next working draft. I’ve tracked the CSSWG from the outside before, its a very frustrating situation. I’m glad the W3C is getting pressure to open up and that some of that pressure is being directed at us.

But I don’t think adopting the HTMLWG model is the best way forward. Critical people like Boris Zbarsky (Mozilla) and Markus Mielke (Microsoft) have already commented that they can’t keep up with the influx of mail there, and feedback from people like them isn’t something we can afford to lose. Above all else, the spec has to be something the implementors scan and want to implement.

The CSSWG doesn’t need a radical restructuring to be more open. We have a structure that, IMHO, works reasonably well, and we have a working group culture that is internally pretty open, amicable, and flexible. What’s missing is collaboration with talented and knowledgeable people outside the working group and an open, two-way, quality conversation with the web design community.

I think the best way for the CSS Working Group to open up is simply to communicate better with the public. I would like to see us

• Revamp our website to be more informative and more relevant.
• Publish a CSS Working Group weblog where we can post ideas, explain our work, and invite feedback from the web design community.
• Set up a public wiki where we can share information, keep track of our open issues and our resolutions, collect ideas submitted to the working group for consideration, and collaborate with people outside the working group to improve our test suites.
• Keep editors’ drafts in a public location so people can see our latest version and how we’re attempting to address their feedback.
• Interact more with sites like css3.info.
• Shift all our internal technical discussion to a public mailing list where others can read our comments, decisions, and rationale and themselves contribute to the spec-writing process. Currently www-style is primarily where we take in feedback and have open discussions, and the internal list is primarily where we process feedback into spec text. If we set up some guidelines to enforce that, the traffic on the new list should remain at a tolerable level.
• Open up the entire test suite development process and make it an independent open source project with contributors and leadership and a peer-review system of its own. The CSSWG itself doesn’t have the time, and doesn’t really need, to be running that show.

We discussed some of these issues at our last face-to-face meeting, and so far have already agreed

• To start a weblog! We’ve even got a couple posts on deck (including a less opinionated remix of my last one). Andy Clarke and Jason Teague have volunteered to cook up a hip, cool, and totally accessible new design in the near future, so stay tuned.
• To set up a wiki to track our work. (I set up an unofficial dokuwiki as a demo before the meeting, which I’m still using for test suite work; the official version may have to be a MoinMoin installation, yuck.)
• To maintain our issues lists in a public space, probably the wiki.
• To make it possible for CSS module editors to put their editor’s drafts in public CVS space. (Not all specs will move there, because some of our editors are uncomfortable editing in public, but you can expect anything I edit and anything David Baron edits to wind up there and hopefully most others as well. As David Baron says, he’s uncomfortable not editing in public.)
• To move most of our discussion to a public mailing list once we’ve sorted out the necessary IPR issues. Basically, anyone contributing significantly to the spec would need to agree to the W3C Patent Policy. This will probably take the form of something like a W3C Interest Group: editorship and decision-making power will rest with the CSS Working Group (but as I mentioned before we can always pull specific members of the public in as Invited Experts if we want to let them edit).
• To accept new test suite tests, assuming they at least conform to the guidelines, as correct until proven incorrect.

So we’re slowly making progress on this front, and the main blockers right now are technical, legal, and temporal, not organizational.Hopefully by the end of the year we’ll have set everything up and be working together with the web designers, implementors, and random techies towards a more inclusive CSS future.

As for the CSS2.1 Test Suite, I’ve acquired write access so I can edit it. So far I’ve fixed a few bugs, imported a handful of tests Microsoft submitted, and set up some indexing scripts to make a proper table of contents. I’ll probably be spending much more time there once Mozilla 1.9Beta is out. I plan to set up framework for turning it into an open source project rather than just open-sourced code, and hopefully we’ll be able to get the Mozilla, Microsoft, Opera, Webkit, and Hewlett-Packard QA teams, along with random volunteers, to all contribute tests.