I recently came across an old draft post from 2007 that I never published. It looks finished enough to simply push it out as-is. While it was obviously written before the explosion of CSS frameworks and tools like Blueprint and Compass, those don’t really have much impact on the core of what I was saying. I hope you find it useful…
This morning I read a post by Jon Udell that ignited a series of latent thoughts I’ve had, mostly centered around CSS, aspects, and screencasting.
In his post, Matthew Levine’s holy grail, Jon praises the theory of CSS but bemoans the drudgery that so many of us not-a-designer-but-geek-enough-to-try types face at some point or other:
To be honest, although I’m hugely fond of CSS styling, I’ve always struggled with CSS layouts, and I know I’m not the only one in that boat. When you read the explanation in Matthew’s article, you can see why. CSS layout is like one of those games where you slide 15 tiles around in a 16-square matrix. In principle it is a declarative language, but in practice the techniques are highly procedural: Step 1, Step 2, etc.
Jon goes on to request a pattern library for CSS layouts, and while I think it’s a great idea I don’t think it’s enough. In my many years of web programming experience few things been more intriguing and challenging as deconstructing a complex web design from someone else and distilling it to the essentials. In the end, we muddle through, leaving unnecessary HTML and CSS constructs littered throughout our new site. Data needs evolve for the site, invoking the corresponding evolutionary change in the HTML and CSS constructs. The ebb and flow of change ultimately builds up enough sediment in our design that, like your old water heater, you simply throw it out and start afresh.
Why is it so complicated? Isn’t it just colors and a bit of structure? To get good at evolutionary web design takes several things. I believe that first it takes time to understand how web designers approach the process of building a particular template. On top of that it takes a clear understanding of the unbreakable link between HTML structure and CSS — a coupling so tight and so loose at the same time.
For starters, the design process is sufficiently opaque to obscure the reasoning for certain elements. (Is this HTML construct here only to achieve a certain feature? Is that CSS construct there for the same reason, or does it play multiple roles?) Learning more of the tacit knowledge of the evolutionary web design is helpful.
One piece of the puzzle is to understand the design process more in depth. Jon’s been the major proponent of screencasts for a long time. He’s said in his article Screencasting of tacit knowledge:
One of the things that I’ve known tacitly, but never articulated, is that screencasting can be an excellent way to transmit tacit knowledge.
But one of the challenges is transmitting the kind of tacit knowledge involved in CSS design work is that it takes place over a long period of time — way to long to merit a screencast. I recently stumbled across another form of transmitting that kind of tacit knowledge, though. It seems like the time-lapse cousin to the screencast. Dylan Bennett created what he calls a designline:
To create this designline, I took a screenshot basically every time I saved my HTML file. I’m one of those people who impulsively hits Ctrl-S after every tiny little change, so you end up seeing every little change made to the file as it goes. I started out with a blank text file and I go all the way to a completed site design. Check it out.
While CSS has a declarative format, as Jon mentions above, to me it also has the feel of an aspect-oriented language in that a single declaration may cut across a multitude of unrelated elements. One single element may have multiple CSS classes associated with it.