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! Visit site »