CSS Wizardry Grids
Created by Harry Roberts as part of his great Inuit CSS project. Follows a similar principle with the chaining of classes in the markup for each breakpoint, but also allows for the use of ‘silent’ classes, utilising Sass’ @extend function to keep markup clean.
The benefit it has over Proportional Grids is that it uses inline-block for grid cells meaning there is never any need for float clearing which was sometimes an issue. You will need to use <!-- --> comments in between grid cells to remove inline-block whitespace though, or remove it manually. Harry’s grids also include a wider range of column combinations/widths, as well as pushes and pulls for columns to move cells left or right.
Griddle
Created by Necolas whilst working at Twitter. Again, you have to create a set of grids per breakpoint and then chain classes on each grid cell. The benefit with this system is you can choose exactly the proportions you require at which breakpoints, meaning the complied CSS is potentially a lot leaner. I think you can @extend into the grids via Sass should you not want to use multiple classes, but don’t quote me!
Griddle also uses inline-block so again no float issues. It includes handy modifier classes to centre grid items and switch from left-to-right to right-to-left. Whitespace between grid cells is not an issue, taken care of by some letter-spacing and word-spacing trickery.
David Bushell Grids
An idea I am coming around to after David Bushell’s post today is don’t over complicate things and try to define layout too early. Essentially, code things when you need them and not try and cover all bases before you start.
Layout often needs to be specific for the content modules involved. Having recently had to re-build the main structure of a site due to trying too hard to make a pre-defined grid work I can clearly see this logic.
Look for patterns within the content in question and use these to create abstracted grid variations. If all columns always take the same proportions you’re better off defining a unique class on the grid wrapper, rather than one every grid cell.
It’s vital to have a basic grid system you can re-use between projects and this allows for that, merely defining widths on a per-module basis yet always keeping the same grid cell structure in a mere 10 lines of code.
That said, I do like having lots of helper / breakpoint specific grid classes to bring together prototypes quickly so perhaps I’ll take David’s concept and roll my own version with some common defaults e.g. 1 -> 2 – > 4 columns on the next project.
His method uses float for columns, so you’ll need to add your own clear if you’re using multiple rows or perhaps switch up the codebase for an inline-block system. You’ll also need further classes if you want columns to take different widths. But I think that’s the point, create your own grid system for your own needs!
Note: none of the above grids support IE7 out of the box so if your client is still living in the past, as David says in his article serve IE a fixed width and it’s easy to fix.
Addendum:
For a heavily typographic site which is a simpler and without the need for lots of grid layouts, you could do far worse than looking at something like The Goldilocks Approach. It really just builds on the idea of optimum line length for readability on the web, and goes bigger or smaller from there.