CSS future (12:55 -0700)

I read Alex's post on CSS3, and I mostly agree with the sentiment (although not some of the details). As one member of the working group, I'd like to give my take on a few of the issues raised.

One thing that the group has decided (although I think it hasn't been conveyed very well in the titles of documents published in the year or so since then) is that there isn't going to be a single "CSS3". We aren't going to insist that we don't add any more selectors features until all the other current modules in progress are finished (since selectors is close to finished). Instead, each of the modules will be versioned separately, so they can advance at the appropriate pace. I think that's a good thing. (But it does have some disadvantages. See below about publication of documents as modules being too easy.)

A bigger issue is that I (and some other members of the group) have been trying to get the group to do all its work in public. I think this would make it much easier to accept input from those outside the group and give those outside the group a much better idea of what is going on. This has met a bit of resistance from other members of the group.

As a result of wanting the group's work to be public, I haven't objected to publishing documents, on the principle that our documents should be public. I'm now thinking that this was a mistake. Publishing documents as W3C working drafts to the TR page gives them a lot of credibility. Instead, I think I should object to publication of documents that I think are taking CSS in the wrong direction, and object to allowing "one or two people in support and nobody opposed" to be taken as consensus for publishing documents. I think this matches the W3C's definition of consensus better. That said, I still want the group members to make these documents (and more) publicly visible. I just don't want the group to put its weight behind them by putting them on the TR page. I think it would improve both public understanding of what the group is doing and the group's use of its own time if the documents we publish on the TR page are documents that we think should be the highest priorities for the Web and that we expect to be implemented soonest.

But what about the issues of technical direction, and which specs are right for the future of CSS? I think the two biggest issues are:

• When a concept has been around for a long time, we should be focusing on the tried-and-true ways people do it (like hbox and vbox, plus a separate mechanism for content reordering that works with other box models too) rather than inventing new ones without good reason (ASCII art template layout).
• We should be focusing on the right concepts. Web layout standards so far have taken a lot from the history of formatting printed documents and very little from the history of designing user interfaces. We need more of a balance: flexible box layout used for user interfaces should take higher priority than advanced print-based features like grids.

I'd have to quibble with some of the details of Alex's post, though. Writing feature requests in the form of CSS syntax is sometimes useful, but in this case it isn't. There are some serious ambiguities in the @importRule proposal in Alex's post and some potentially serious pitfalls for authors, it's quite complex (although possible) to implement (although it may have to be @importRules), and there may be much simpler solutions that do all (or most) of what he wants from it. It would be nice to know what, exactly, he wants from it. Are macros that contain declarations sufficient? In what cases would you use such macros? I think for the group to make progress on something like macros in CSS we need a wiki page that lists the important use cases. Then we could examine particular proposals, see how many of the use cases they meet, how hard they are to use and to implement, and what issues they might cause for maintaining CSS over time, for editing tools, etc.