Why We Chose 960.gs for Our CSS Framework
A few months back, we redesigned Onehub.com to coincide with the public launch of the Onehub service. There were a ton of goals to achieve with the new design from education, sales and marketing perspectives. I also had my own hidden agenda which resulted in us implementing a CSS framework.
Leading up to the public launch, the breadth and depth of the site had started growing at a pretty good clip. The design and messaging of Onehub.com were already incredibly important to me and their importance was only going to increase post-launch. That being said, the amount of time it was going to take to maintain the site, was just as important to me. After all, if given the choice, I would much rather spend my time on the Onehub service – designing new features and improving existing ones for our customers.
I knew that maintaining Onehub.com in it’s current state was going to start pulling me away from the product. Something was going to have to give. Or was it?
What I wanted to accomplish
I needed to make Onehub.com much easier to maintain but wanted to do it without sacrificing style and flexibility. I was not specifically looking for a CSS framework in the beginning. In fact, I understood at face value why you might actually want to avoid them. However, after realizing that it wouldn’t make sense to leverage the existing Onehub CSS framework, I drafted a simple list of requirements (based on the typical cons of CSS frameworks) and went on the hunt.
Our requirements
- Should be easy to learn
- Should be easy to maintain
- Should have a small footprint
- Should be as semantic as possible
The frameworks that were considered
There are a bunch. I tried most of them and immediately narrowed the list down to 960.gs, Boilerplate, Tripoli, Blueprint and YUI. From here, the only one I immediately disliked was YUI – thanks to crazy naming conventions and some overkill. Of the remaining 4, it mostly came down to personal preference. Blueprint and Tripoli did more than what I was looking for. Boilerplate did less.
960.gs emerged as the framework that I felt had the potential to be most useful most often. Here is why it worked particularly well for us.
Easy to learn
Quite frankly, the learning curve for 960.gs is almost non-existent. If you already understand the concept of grids and the necessity for having access to the first and last items in a given collection – understanding the 960.gs syntax is a piece of cake.
You’ve got two grids to choose from. One that allows for 12 columns and one for 16. Want a 3 column layout? Create a 12 column container and fill it with 3 elements, each 4 columns wide:
<div class="container_12"> <div id="blog" class="grid_4"></div> <div id="photos" class=grid_4"></div> <div id="links" class="grid_4"></div> </div>
No really. It’s that easy.
Easy to maintain
Because 960.gs is so easy to learn, it is naturally easier to maintain. Getting multiple designers on the same page can be as simple as showing them the code snippet above and having them go to town. If you buy in to the 960.gs conventions, you can immediately begin taking advantage of it in your work flow.
Furthermore, 960.gs is browser compliant all the way down to IE6. Now, you can certainly mess that up if you try, but it is absolutely killer to be able to rely on a bulletproof grid out of the gates.
Has a small footprint
I didn’t use the text.css file from 960.gs as everything it covered was going to be redone anyway. That left us with Eric Meyer’s CSS Reset and the main 960.css file which is a mere (3.6 KB) when compressed. It is brilliantly small. See for yourself:
The only tweaks that I made, were in implementing some snazzy, automatic float clearing to the 960.gs containers and .alpha classes. Everything else is custom CSS on top of 960.gs for the Onehub.com design.
As semantic as possible
Let’s be honest. In order to make a CSS framework useful, you’re going to have to make some sacrifices when it comes to semantics and naming conventions. I think Nathan Smith, the guy behind 960.gs, made some incredibly smart ones.
Most of us use something like container or wrapper for classing our containing elements. If you want a container that allows for 16 columns using 960.gs, you’d use:
<div class="container_16"></div>
Are you mixing some structure in to your class names with the 16? Sure. Is it worth it? I’ll say. It doesn’t make the class any less descriptive. In fact, depending on how you see it, one could argue that it adds clarity. If another designer were to see this HTML they now know it is a container element and contains 16 columns.
Remember, the underlying purpose of being semantic is to avoid having to revisit the structure of your site as often as you revisit the style of your site. Adding the 16 in this particular case does not make it any more or less likely that you’ll need to revisit that code.
Point being, choose your battles wisely. In the time you could argue the relevance of naming conventions like these – I just built a 16-column layout.
For the interior elements, Nathan also chose to avoid the common practice of repeatedly typing a class name like column as well as a number designator. Rather, he combined them in to one. Furthermore, using grid in the name further reinforces the idea of making multiple designers aware of the grid when they go in to edit the HTML.
I’m also a fan of the alpha/omega classes in place of a traditional first/last. Though it doesn’t seem like a big deal at first, I think it is a clever way of conveying the meaning of first/last while adding back a tiny bit of flexibility. It is also a life saver for the handful of times when you decide to break up your grid and nest grid elements inside each other.
960.gs gets you on a grid and then gets out of your way
Converting all of our mockups for the Onehub redesign to working layouts took a single day. Integrating our existing content took another day. After that, it was all polish.
After launch, rolling on 960.gs has allowed us to continue to design and maintain Onehub.com faster, with fewer mistakes and without having to worry about IE for the majority of our layout issues. This allows us to spend the majority of our time on the creative aspects and the messaging of Onehub.com.
Most importantly, it gives me more time to spend on the product. This makes me and our customers happier and I simply can’t argue with that.