CSS WG Blog David Baron on Designing CSS

David Baron on Designing CSS

I thought David Baron’s reply to Andy Clarke’s recent speculation was extremely well-written and had a lot of important things to say about the CSS Working Group. I believe most of the working group members would agree with his statements. I’m quoting it here so more people can see.

I disagree with the claim that browser developers only want small improvements in standards. Many of us—particularly those of us whose interests are aligned with seeing the Web as a successful platform—want both small improvements and big steps forward.

We want small improvements in the details of the spec because we get complaints every time something works differently in different browsers, and we need something that says who’s right and who’s wrong, and a forum to discuss the issue when the existing spec isn’t clear. This lets us actually improve browser interoperability rather than each hiding in our respective corners and saying “the spec isn’t clear, and *our* way is better.” This refinement doesn’t stop: as standards become more mature, authors expect more precise interoperability, because *somebody* is always pushing the edges of what can be done with any heavily used Web technology.

We also want big improvements too. We want these so we can make the Web a better place for users and a better place for authors to reach those users (easier for authors to produce content, easier for *more* authors to do so, etc.). Building entirely new capabilities into standards is a lot of work. Going from “we want to be able to do X” or “we want a better way to do Y” to having the best way to do X in place and usable by authors is a lot of work. First, you need to figure out what exactly the best way to do X is, where best is determined by how easy it is for authors to use, how good the result is for users, and how long it will take to get that result in place (spec writing and implementation). There are lots of hard trade-offs involved. Then you need to write a spec, and (if you want interoperability) a test suite, and then (if you succeed in getting implementations) you need to continue through many cycles of the refinement process I described above.

As Mozilla’s representative to the CSS working group, and one of a relatively small number of active people on the group (although not as active as some other people), I find all the things to do here overwhelming. There’s a long list of things that I think the CSS working group should do immediately, but I just can’t do all of them. Given that standards work is only a part of my job (currently, at least), I often don’t have time to do any of them.

I strongly agree that the group should become more public and try to change so that it is welcoming to contributions. That said, potential contributors need to understand that developing a successful spec is hard work and might not be quite what they expect. And I don’t think trying to kick the browser makers out will help you any—you’ll lose a lot of expertise about existing specifications *and how they interact with each other*, and you’ll find it harder to get implementations of specs whose design didn’t take cost of implementation (and thus time-to-wide-deployment) into account.

« Previous article Next article »