Wow. Less than 24 hours after my last post, there have been nearly 100 comments posted, and I’ve seemingly managed to piss off half the Internet. It seems some people took major offense to my thoughts, although no one has came forward to told me why (Andy Budd said on Twitter, “you’ve managed to tick off quite a few ‘limeys’ with your post,” but he didn’t answer when I asked why.
Of all the topics I’ve ever written about, I would have thought CSS frameworks would be one of the most non-controversial. Apparently, not so. I thought I’d follow up by trying to detail what I’ve learned after a century of commentary on the past in question.
The first thing I learned from the comments is that different people have very different ideas of what a framework is. In my Frameworks for Designers article at A List Apart, I defined a framework as follows:
The point of the article, and my point every time I’ve said that I think CSS frameworks are a good idea, is that by abstracting commonly-used CSS into reusable bits of code and coming up with reusable
id naming conventions, designers and developers can enjoy increased productivity. This seems so obvious and stupidly simple to me that I almost didn’t write the A List Apart article — I remember telling Erin Kissane (ALA’s Editor-In-Chief) that I wasn’t sure there was enough “meat” to this topic to even make it worth writing about. But I was wrong — within hours of writing the piece, there was quite a discussion going on about it, and several “haters” (for lack of a better term) coming out of the woodwork to denounce the idea of CSS abstraction. I was surprised — as I said, it seemed to me that the concept of reusing CSS code for efficiency was entirely non-controversial.
Part of the reason I was surprised is that I thought this kind of abstraction was something all experienced CSS developers already did. I didn’t think I was saying anything revolutionary — I thought I was just outlining some ways you can do it, and how it can increase your efficiency.
After reading the comments, I think I was right. Most top-tier CSS developers do deal with a framework of sorts — they just don’t call it that. They call it a “library,” or “snippets” or “defaults” or “baseline” — but it’s all the same thing. It is, as I defined above, “a set of tools, libraries, conventions, and best practices that attempt to abstract routine tasks into generic modules that can be reused.”
The second thing I learned from the comments is that people seem to confuse the idea of CSS frameworks with the individual implementations of one or two popular, publicly-available frameworks.
Since I wrote the A List Apart piece, CSS frameworks have gotten a lot more play, in large part because of the release of Blueprint CSS, a framework which is largely based off non-released code I wrote (along with my co-workers) at my previous job (if I thought the code was appropriate for everyone, I would have released it myself — but I didn’t, so I didn’t). Unfortunately, it seems as though people are now unable to separate the basic concepts of abstracting CSS for time-saving from the product that is Blueprint CSS. Some folks don’t like certain aspects of Blueprint, and are denouncing the entire CSS framework concept because of it (as I said in the comments of the last post, this is a bit like saying you don’t like automobiles because Hummers are total gas-guzzlers).
In my recent post, I was very conscientious to write about the concept of frameworks and not about any particular framework. I have some qualms with every CSS framework I’ve looked at (and I’ve looked at all of the publicly-available ones — and some private ones, too). None of them are perfect. But they all strive to meet the same basic goal: to establish some reusable methodology such that developers don’t have to reinvent the wheel on every site they build. My opinion is that this is a very good thing, even if none of the publicly available frameworks quite do it exactly the way I would if I wrote my own, all by my lonesome.
It shouldn’t be any surprise that I like Blueprint a lot. After all, the concepts included in it are mostly my own. But it very well may be that it doesn’t work for you. This doesn’t mean the time-saving ideas behind CSS frameworks are dead to you. It doesn’t mean you should publicly denounce the entire idea as ridiculous. If you’re interested in getting these benefits without using an off-the-shelf CSS solution, consider writing your own framework. It can be as ambitious as you like. Maybe you just need some basic reset styles. Maybe you just need to come up with a consistent class naming convention. Maybe you want a much-larger, more all-encompassing solution. The point is the same in every case: if you write a lot of CSS, you’ll probably save yourself a lot of time in the long run by putting some short-term effort towards abstracting some of your commonly-used ideas into reusable bits. That’s really all I’m suggesting. It still doesn’t seem very controversial to me.
The third thing I’ve learned is that: g’damn some people need to get out more. Seriously, folks. As a friend said over IM, we’re not talking about landing jets here. We’ve basically won the web standards war, and now some people are trying their hardest to create other little wars they can wage and win, because it makes them feel important.
Why can’t we all just hold hands and sing kumbaya or something?