Natalie (who, for the record, is one of the friendliest people I’ve ever met!) has some really great tips for writing CSS in her slides from a recent talk. Be sure to download the PDF version, which includes her notes. One of my favorite bits in here is her definition of the difference between a framework and a library. It may not be perfect, but it’s the best I’ve heard, especially as it relates to CSS frameworks (and God knows I’ve struggled to come up with a definition myself):
I feel the need to define what I call a framework. For me this is something that alters how you write HTML itself. This is different from a library, which simply provides individually reusable components.
This is a really solid definition (even if it means I’ve been using the word “framework” incorrectly), and it pretty well encapsulates the reason why I really liked Blueprint when it was released, and am not such a big fan anymore. When Blueprint first came out, it was much closer to the library side, wherein it didn’t define how you write your HTML (at least: not very much). Today, it requires you to liter your markup with tons of div elements -- and while this doesn't do much real-world harm, it does sort of bother the aesthetics of us who grew up on web standards and best practices.
As you might expect from something coming out of the Clearleft camp, Natalie’s CSS System presentation seems pretty focused on their usually-fluid-width, non-pixel-precise sort of design, but I think most of the concepts within can be tweaked to work for those of us who are more about the whole “make something in Photoshop and then make the browser version of it replicate that as closely as possible” approach.
Even though Natalie says she doesn’t like CSS frameworks, I think her CSS system approach actually has a lot in common with the idea of a framework (or library, or whatever you want to call it). In the end, the point of both is to come up with reusable, consistent development patterns that allow you to work in a way that’s more efficient, maintainable, and elegant.
People — especially those who seem to oppose the idea of frameworks for CSS — like to point out that CSS isn’t programming. Of course it’s not. But it is code. And it turns out that our programmer friends are a helluva lot better at managing code than most of us designers are. One of the main ways programmers manage code is to refactor things into a framework. And although not all of the framework concepts may translate well to CSS, the core idea of writing, storing, and maintaining your code in such a way that encourages reusability, offers “baked-in” browser compatibility, provides sensible defaults and hooks for overriding them, and keeps you from repeating yourself is smart stuff, and I’m glad to see other front-end developers finally starting to get on board.
As I talk to people who write CSS for a living, I’m constantly shocked at just how much people repeat themselves and make their life more difficult in the long run by not reusing code (and by “reusing,” I don’t mean copying-and-pasting).
Well done, Nat!
001 // Nate Klaiber // 09.29.2008 // 6:54 AM
While I am not keen on CSS frameworks (personally), I don’t think that they are worthless or unusable. As you have said before, it is another tool in our toolbox of things to use as developers.
In regards to programming and the comparisons. I only point out that CSS isn’t programming, when the hordes of designers come in with their different approaches (hybrid/php/ruby/whatever) to make CSS function like a programming language, only adding another approach to the mix, as well as unnecessary overhead. This is not a slap on designers, I just haven’t found well thought-out approaches that don’t complicate things unnecessarily.
In regards to managing your code, that makes complete and perfect sense. The same would be true of HTML, in wanting to keep it lean, semantic, and useful. The CSS side of things would mean using the cascade and inheritance in a way that allows you to maximize your re-use, portability, and maintainability.
Now to go read the actual article, I just wanted to give my opinion on your opinion. ha.
002 // Simon Willison // 09.29.2008 // 8:13 AM
The key idea behind CSS systems is that you create a set of reusable styles for an individual site, which fit that site’s design and domain concepts. The “system” is the combination of CSS, reusable markup snippets and supporting documentation, whatever form that may take, which can be handed over to the developers maintaining the site and hence enable them to maintain the big picture while making changes to the code.
If you like, “CSS systems” just means that you create a new, documented framework for each site that you work on. And of course, you may well start by bringing in reusable styles from your existing library of code.
Nat will be the first to admit that this process isn’t a new idea (in fact she was sure that noone would want to hear about it as they’d all be doing it already; I had to convince her that it was worth explaining) - but I think this is one of those things where by giving it a name you give people the ability to discuss, share and understand the wider concept. I’m really excited about that.
003 // Jeff Croft // 09.29.2008 // 9:46 AM
Well, I certainly wasn’t referring to you specifically, but in general, I agree with you: most of the stuff you’re referring to is way over-engineered, and while it’s sometimes clever and interesting to play with, it’s not really for me, personally.
Yep. I got it. :)
I think one of the concepts that has always been missed in the whole CSS frameworks idea is that they definitely shouldn’t be used as-is from site to site. They’re designed (well, at least the good ones) to be sensible defaults which can and should be overridden. If anyone plugs in Blueprint without overriding many of the styles, they’re kind of missing the point.
Right. And this is, more or less, the exact process I’ve been advocating ever since I wrote the CSS frameworks article on A List Apart. I think, in hindsight, I was wrong to use the word “framework” in that article, but the concept is more or less the same, I believe.
Heh. That’s actually exactly what I thought before I wrote the CSS frameworks articles on ALA. Erin Kissane convinced me to write it after I told her, “I’m not really sure this has much value; most people are doing this stuff already.” Turns out, people were very interested in it (both in a positive and negative way), and it seems like they still are, given the reaction to Nat’s presentation!
I agree completely. I’m excited about it, too. I feel like I did the same thing, in a way, when I wrote that ALA article, but I (unknowingly) gave it a very divisive name (“CSS framework”), which has sort of sidetracked the discussion ever since. People got so hung up on their aversion to the word “framework” that they ignored the points of the article: that common patterns and reusable code make one more efficient.
I’m glad Nat gave this stuff a better name, and I hope it generates a more productive discussion than my article ever did. I do realize Nat’s ideals about CSS differ from mine in some ways, but what has me excited is, like you said, that people are discussing how we can make CSS more efficient and elegant, both from a writing and maintaining standpoint. It’s sort of akin to Django vs. Rails: the two may go about things in different ways, but at the core they’re both trying to solve the same problems, and they have a lot more in common than they do differences.
004 // Vladimir Carrer // 09.29.2008 // 3:44 PM
CSS Systems = CSS Framework! Reusable and organized CSS code = CSS Framework or CSS System or call it what you want!
We have private and public CSS Frameworks, we have “semantic” and non “semantic” CSS Frameworks. We have Grid CSS Frameworks we have Print CSS Frameworks …
@Jeff: I think we must find one solid definition for CSS Framework.
What is CSS Framework?
005 // Justin Lilly // 09.30.2008 // 2 PM
From the original post ^^