Does anyone actually read this?

I've been emailing some of my designer/developer heroes asking for opinions on CSS frameworks. Not sure if those efforts will bear any fruit, but in the past even the rock stars of the industry have been pretty approachable.

I thought I might as well try to get the conversation going here as well. (Assuming anyone is actually out there with whom to converse.)

My thoughts on what I've seen so far have not been good. Even Google, who usually awakens my inner fan boy, seems to miss the boat on this one. (Just got confirmation from John Resig [I told you even the rock stars are approachable] that Blueprint is hosted by Google Code but isn't itself a Google product. Apparently I'm not alone in my confusion. Still, it's the de facto king of CSS frameworks so I'll continue to pick on it anyway.) Blueprint strikes me as a tangled mess of presentational class names. Actually, forms.css isn't so bad. It's got .title, .text, .error, .notice, and .success. Those classes make semantic sense. I can see myself actually using the core ideas behind that style sheet if not the actual framework code itself. And it's things like that which give me hope for the general idea of a CSS framework. tyopgraphy.css starts to get a bit more iffy. As much as I hate the idea of classes like .left and .right for floating images within text, I have to admit I often use them myself. So I can't point too many fingers there. Classes like .added and .removed have obvious uses for AJAX-y goodness. And I can see uses for classes such as .first and .last assuming they are applied dynamically (by jQuery, for example). I can even imagine common uses for classes like .small & .large and .quiet & .loud, but those start to fall outside my personal comfort level when it comes to putting non-semantic, presentational classes into my markup.

The deal killer for me is grid.css, which is really the main selling point of the idea of a CSS framework. Almost everything in that style sheet is purely presentational.

Let's say I'm building a site using Blueprint to do a basic 3 column layout. I start out with 6-12-6 and put the needed classes into the markup to accomplish that. I build a couple hundred pages and put it into production. A few months later I realize that the sort of content I've got going down the right hand side (AdSense, social bookmarking feeds, etc) is not coequal with the primary navigation in the left column and I want to shift things a bit to say 7-13-4. Now I have to alter class names on a few hundred pages worth of markup rather than making these presentational edits to the CSS where they really belong.

“But you could easily do that with a find/replace. Quit yer bitchin'.”

Ok, that's true. I see your find/replace and raise you a redesign requiring a horizontal primary navigation menu. If you're keeping your markup all Zen-like, you edit one file and the changes magically appear site wide. You might still conceivably be able to pull off such a change with a few find/replace operations using Blueprint (or any other grid based CSS framework using presentational class names, I'm using Blueprint as an example but just about everything I've seen suffers the same flaws). But it would take some pretty complex work. And even running find/replace across hundreds of pages of markup is more work than changing a couple of rules in a centrally located CSS file.

But this is a lot like how I felt about js frameworks vs. rolling my own unobtrusive DOM scripting before I found jQuery. I knew there was potential there, but I just wasn't seeing enough trade off in benefit offered in exchange for giving up so much control of my code. It helped the jQuery applies CSS style selector logic to scripting and thus meshed well with the way my brain already thinks about these things. I imagine if I had both the time and talent required to build my own js framework, it would end up working a lot like jQuery. I have yet to experience that with a CSS framework.

Exploring the Potential

I haven't taken an in depth look at everything yet, but there are two CSS frameworks that managed to not send me running away screaming after mere moments of peaking at the source code of the available demos.

1. Boilerplate
2. Content with Style

The language used to introduce the concept on the home page for Boilerplate is enough to get me findin' religion.

As one of the original authors of Blueprint CSS I've decided to re-factor my ideas into a stripped down framework which provides the bare essentials to begin any project. This framework will be lite and strive not to suggest un-semantic naming conventions. You're the designer and your craft is important.

If you prefer:

 { float: left; width: 240px; margin-right: 110px; }

over

class="column span-2 append-1"

then you're in the right place my friend.

Yes! But wait, it's only at version number 0.3 and it looks like that version is nearly a year old. Is my best lead effectively abandonware? That makes me a sad panda. Still, it may give me a good place from which to start future projects. Let's download this bad boy and take a look under the hood.

Not significantly different from Blueprint. I see an almost identical typography.css file, down to the somewhat uncomfortable .small & .large. There's also .quite, but no .loud. I'm also seeing a pretty basic reset.css (I personal prefer to slightly modified version of Eric Meyer's Reset Reloaded), a small collection of basic IE hacks in ie.css, and a few form styles that aren't really enough to save me significant time vs. writing my own from scratch or cannibalizing my own back catalog.

While Boilerplate avoids going deeply enough into the realm of presentational class names to catch my ire, I'm not seeing much in the way of benefit here either. At least with Blueprint I could wireframe something up in a day to show to a client, even if it's not the sort of thing I would want to put into production. I see nothing mind blowing here. Maybe if it ever hits version 1.0 I'll take another look. :(

Moving on to Content with Style. Yes, this is better. But it seems more like a philosophy more so than a true framework. Maybe I'll feel different after checking out the source code. This also hasn't been updated in just over a year (and then only once, and that wasn't really a change to the code at all, just a license addition). That also contributes to an overall feeling that I'm better off applying the underlying ideas to my own design work rather than using these exact files. But that's pretty much how I feel about Blueprint. I can figure out which classes would apply to a given element in the design I aim to achieve and rather than apply those class names to the element I could simply apply the styles for that class to whatever semantic class or ID I use for that element. The philosophy is sound. It's just the execution that leaves a bad taste in my mouth.

Looking at the code feels a lot like looking at my own code. But rather than feeling like the epiphany behind jQuery, this just feels like a slightly more systematic method of reusing the code snippets I've been using for years. It's far from bad. It's quite good in fact. But it's nothing I couldn't do myself. And by doing it myself it will mesh better with the way I approach things and thus be more usable and useful.

Why I Care

My biggest concern is that those currently learning CSS will fall back on these frameworks to save time for things like class projects or one off work for portfolio fodder. In those situations, giving up the separation of content and style to gain a bit of agility is probably justified. But I fear that in the process the vast majority of the next generation of web developers will miss out on the philosophical core of web standards. I think it could set back the industry, right at the time when I was finally starting to feel that education (both formal and informal) was starting to get things right in this industry.

Or maybe I'm chicken little and the sky isn't really falling.