Phil Wallach

Eric Meyer’s comments on Streamlining CSS sparked some further thoughts (always a good thing).

Eric was (unsurprisingly) talking about changing the standard (and therefore browser behaviour), which I had (also unsurprisingly) considered to be way beyond the scope of what I could consider.  My approach was therefore to focus on the build system, which was not only the part of the equation I knew best, but also avoided any standards/browser issues.

But what if I removed that limitation?  If I wanted to add a processing capability to CSS, what would I change and why?  Broadly I see three alternatives.

Build stage

Processing is performed at the build stage and the resulting CSS is loaded onto the webserver as a static page.  This is the approach I took previously.  There is no change to the standard and no change to browser or webserver behaviour.

If this was specified as a standard, it would not so much be a standard defining a message format (which is what CSS really is), but a new language.  This would be in addition to the existing standard.

It may also change the nature of developing CSS; it may no longer be useable by creative people, who may need a build systems, and then we go down the path of programmers, infrastructure, and so on.  A worse idea. (While the idea that there are folks out there creating systems without the guiding light of build systems and, even worse, SCM makes my heart flutter, I can accept that this is a boon to creative people and a necessary evil if they are to stay creative).

This approach would be fine for a specific project or shop that “rolled their own”, or as a product that pre-processed CSS.  Such an approach would be transparent to both the webserver and the browser.

Server-side

Variables are resolved at the webserver and the resulting CSS is passed to the browser.  The CSS standard is unchanged and browsers do not change, but there is a new standard for the “raw” CSS and webservers must change to process “raw” CSS and produce “standard” CSS.

For a start this introduces a new standard for the “raw” CSS, adding to the exisiting standard for CSS.
While webservers have long handed of all sorts of processing (e.g. ColdFusion, PHP, etc), the idea of mandating some form of inbuilt processing just seems wrong to me.  It changes the model too much.

Again this approach would be fine for a specific project or shop that “rolled their own”, or as a webserver plugin product.  Such an approach could only run from specific servers, but would be transparent to the browser.

Client-side

The webserver passes the new style CSS files to the browser where processing is performed.  The CSS standard and browser behaviour both change.

While the idea of changing browsers the web over to a new way of doing CSS makes my head spin, this is easily the best solution.  It maintains the focus, direction, architecture and relationships of CSS.  So while *how* CSS works has changed, the *way* CSS works hasn’t.  It is also the only solution that keeps *one* CSS standard.

This is clearly the preferred standards-based solution. 

Summary

In some ways I have come the long way round and ended up where I began.  The naive solution to this problem would be the same as mine, I suspect - change the existing standard and add the features you want.  But it is always wise to consider the alternatives.