Why CSS Frameworks?

CSS frameworks or libraries are intended to solve the same problems as any programming library – to make certain tasks easier, and to standardise repetitive work. They grew from various front end developers realising they were doing the same cross browser resets and layout setups over and over again, who refined these standard parts of their processes and released them publicly.

These frameworks can be, and have been, used to layout production sites, but they are perfect for prototyping and ‘undesigned’ areas – the administration pages, web GUIs and intranets that are often left entirely to the developer in terms of the look and feel. They offer easy and straightforward ways of putting together better looking and easier to use sites, by encouraging the use of some basic principles of design.

It’s far from uncommon to find PHP programmers that avoid the front end part of web development entirely, preferring to leave styling and display issues to more front-end amicable team members. CSS frameworks are a perfect fit for these back-end oriented developers as they provide a good set of defaults, and allow layouts to be built without having to worry too much about cross browser compatability.

One thing worth pointing out now is that using a standard library may mean your markup is somewhat less clean than it could be – either through using divs instead of a more semantically relevant element, or through addition of extra tags. While none of the libraries bloat out the markup to a worrying degree, they are designed to be fast and flexible, which, in common with most libraries, mean they have to support the generically applicable over the specifically optimal.

Getting Graphic

There are two core components in most CSS frameworks. The first is a reset, which establishes a common baseline, due to different browsers providing slightly different default styling. This usually is accompanied by some sensible, attractive defaults, though these are something optional or included separately.

The second component is a grid system, which is a technique widely used in graphic design. All graphic design, in print, on screen, or on the side of a bus, consists of a set of visual elements – such as lines, text or images, which can be described in terms of their colour, their texture and their visual weight. These are then related in an arrangement where the designer will create relationships between items through use of contrast, repetition, alignment and proximity.

The designer uses these tools to try and achieve a certain result in how the viewer interprets or experiences the designed piece. Too often, this toolbox is used accidentally, without thought as to what effect it might have. For a (somewhat contrived) example, consider a business card that looked something like:

Here we can see various tools of arrangement misused to varying degrees. The card is just about aligned centrally, which it balance but is visually uninteresting. The font is consistent (at least there’s no Comic Sans), but the contrast is misused – the contact details seem very distinct from the address for example. Positionally, the role and the address seem visually related, as they are at the same font size and close to each other, while the name is pushed up on it’s own, and seems only to have a similar importance to the title and address.

Simply aligning the card to the left and establishing a visual hierarchy with font weight and spacing produces a better image:


There’s a whole lot more that could be done to improve the card, but it becomes harder to keep track of the relations between the various items on the page as the layout becomes more complex, and easier for unintended visual effects to creep in. This is where the grid comes in.

A grid is a way to organise visual elements, and behaves exactly as you might imagine, providing spaces to slot into. By following a grid the designer can ensure that items are aligned, spacing between them is consistent, the size of one item is related to another, and that these rules apply equally across multiple pages – whether in a magazine or on a website. The visual rhythm this establishes makes the page easier and more pleasant for the viewer, but also allows the designer to create a greater reaction when they use a different spacing, sizing, or positioning deliberately.

For our uses, the advantage of the grid is alignment and consistency, so that all the elements of a site are visually related and harmonious. While grids used in print media are usually horizontal and vertical, CSS grids usually subdivide the page only into columns – but use of ems for vertical margins and padding will allow you to achieve some levels of consistency in rows.

For an example, here’s the grid of the Avalonstart website which uses the first framework we’ll look at, 960.gs.


On The Grid

wireframeThe first framework we’re going to look at is the 960 grid system, available from http://960.gs/. 960.gs, as the name implies, provides a 960 pixel wide grid – for a 1024 resolution – consisting of 12 or 16 columns. In the 16 column grid each column is 60 pixels wide, with 40px of content space, and a 10px gutter, or margin, either side. We’re going to use that to build up a simple page in a pretty short amount of time.

Our initial thumbnail (created very quickly in Balsamiq Mockups) looks a bit like this, with a big logo top left, a login box top right, then two content areas and some promotional boxes along the bottom.

Lets implement the page, starting with the top section. First up, we need to include the framework files. These can be found on the 960 page in a zip with a variety of other assets for design work. The files we want are in the CSS directory, and assuming this has been copied into the same directory as your project, can be included as usual in theof the HTML.

To choose between the two different 960px grids, you set the class of a container to your preferred option. This, along with most of the grid elements, is usually a div but the element type is not specified in the CSS, so others are possibles.

There are, of course, myriad ways of implementing any design, but for this one we’ll use three containers for the top, middle and bottom of the page, each themselves containing 960 styled sections. When the classes are used inside each other like this it’s important to tag the first one ‘alpha’, and the last one ‘omega’. Here’s the top section:

Logo Here


Here we’ve divided the 16 grid into three units. The first is an H1, which is taking up half of the width. Next are two divs which might contain login boxes, both styled to take up a quarter of the space together. There would already be some margin between these items due to the spacing on the grid, but to make sure they line up with the right of the page, ‘login’ div has another 960.gs class added, ‘prefix_4′. This simply adds padding equivalent to 4 grid units to the left – there’s a corresponding set of ‘suffix_’ classes.

The middle and bottom parts follow the same pattern:

Logo Here



More stuff

Promo box 1
Promox box 2
Promo box 4

Note that the middle section requires an ‘alpha’ and ‘omega’ even though there are only the two boxes in the grid. Adding some padding and colours to highlight the blocks, the page structure looks something like this:


If this were a prototype for a production site, we might now experiment with different content until everyone’s happy, then convert some of the items to more semantically relevant HTML, having benefited from the flexibility of the framework when we needed it most.


Yahoo’s YUI toolkit was designed to provide standardised Javascript interfaces, and it makes sense that they would have some standardised CSS to go along with it. To make putting layouts together even easier they’ve provided a grid building tool: http://developer.yahoo.com/yui/grids/builder, where creating a analogous setup to the above takes just a few clicks. Of course you can use the library without the builder, and there are plenty of examples on the YUI grids page.

Getting started is easy, as being a Yahoo system we can include the CSS file directly from them.

The YUI system works somewhat differently to 960.gs, but there are a number of similarities. Unlike 960, there are four widths available, 750px, 950px, 100%, and 974px, which are triggered by creating a div with an id of doc, doc2, doc3 or doc4. For example, we might be using doc2, 950px.

Sections are grouped in divs classed ‘yui-g’, for grid, and units inside that grid are yui-u. Similarly to 960’s ‘alpha’, the first element in a row of grid elements needs to be classed ‘first’. Each yui-u takes up half of the available space. The middle section with our two content blocks would therefore be styled like this:

When more complex layouts are needed, yui-g’s themselves can be combined using ‘first’, as seen in the bottom section which here we’ve divided into four equal sized blocks.

Blueprint CSS

The other major CSS framework in use at the moment is Blueprint CSS. Much like YUI, there is a build tool available but unlike YUI this is a true grid builder – the width, gutters and number of grids can be specified to generate you an entirely new grid.css file, which can be minified using a bundled ruby script. If you don’t want to use the tool though, the default grid gives you a 950px page with 24 grid columns, at 30px with a 10px gutter.

For those working in Drupal or WordPress, there are already themes setup that use the framework: http://wiki.github.com/joshuaclayton/blueprint-css/themes-and-frameworks. For everyone else, we’ll need to included the blueprint files. If using the standard setup, or the minified version has been rebuilt (the originals are all in the ‘src’ directory), this is as simple as:

In common with the other frameworks, blueprint pages need a container, helpfully called ‘container’. It’s a class so you can use multiple of them to create rows of content.

The sections within are generated with span-X classes, similar to grid_X in 960. Also similarly there are append-X and prepend-X classes to add padding before or after a block, but there are also pull-X and push-X that allow a block to be pulled or pushed into surrounding sections of the grid. You’ll also want to class each section with ‘column’. To build the top block of our page, we might use the following:


Note that the ‘first’ and ‘last’ are needed on the first and last elements within a container, even if there is only a single element:

One very useful tool included in blueprint is the ‘showgrid’ class. Add this to any element (usually the container) and it will add a background png displaying the grids and gutters underneath, which can be helpful in making sure everything lines up properly. The grid builder mentioned above also generates this png to fit your custom grid.

On top of the grid, blueprint also provides some typographical classes that can be applied, coming as part of one of the default plugins. These can be added into the minified CSS file through the ruby script, or for prototype work just included directly:

These classes include .caps for a small caps display, .incr for incremental leading and a .alt for some fancier font selections. Other standard plugins include some CSS buttons and link icons, and there are more to be found on the blueprint wiki. The best documentation for each is usually the css file itself.

There is an off-shoot of Blueprint by one of the original creators, known as Boilerplate CSS that focuses on providing a minimal core of totally reusable code. It’s less focused on the predefined grid classes than the other frameworks we’ve looked at, which might appeal.

Next Generation?

Fluid Grids

Some of the more recent CSS frameworks have moved from a fixed width to a fluid grid. Fluid 960 for example, is, as the name suggests, a fluid or variable width implementation of the 960 grid system, and works almost exactly the same way, but with grids based on percentages rather than fixes pixel sizes.


The idea behind Nicole Sullivan’s OO CSS grew out of the problems many developers have observed with larger sites -the amount of CSS also grows, and as it does it becomes less manageable, and less comprehensible. What appears the same visually on two different pages may result from a completely different set of styling rules, and the whole thing takes on the very worst aspects of spaghetti code that we strive to avoid in regular development.

The OO CSS idea is that the spaghetti situation is avoided through use of small modules or blocks of code, and strong separation between various layers of functionality. This also helps improve the repetition and consistency throughout the site.

Though the OO CSS framework itself is still in it’s early stages, the basic idea of separating layout and ‘theme’ elements of individual modules (structure and skin), then strictly reusing those modules with appropriate styling on what’s within them (separating container and content), can benefit almost any site system. The project is definitely one to watch, and there’s a great summary of the ideas on Nicole’s blog.


It’s easy to dismiss these kind of libraries – as either being part of the area you’re not interested in, or as as a cause of markup or CSS bloat, but the advantages they can give in terms of speed, consistency and flexibility can be really significant. This is particularly true in prototyping and rapid development situations, but the tools can be just as useful on intranet apps, administration pages and the rest of the large number of sites built not for the general public, and hence often without the input of a designer.

Improvements here can yield big dividends for the users of these systems, without too much pain. It doesn’t take much to drop them into a project and add the required markup, so next time you’re putting together a page try giving a CSS framework a go, and see what a difference it can make.