Grids

Written on 15 April, 2012

Grids are great, and using them within your web development is a very good habit to have.

I'd like to think the majority of designers and developers are fully aware of this by now as the industry gradually realised those graphic designers were actually onto something. If you're not experimenting with grids, you should probably make it a priority to change that. Mark Boulton has written many wise words on the topic of grids, and how you should be looking to use them on the web, it's certainly worth checking his books and articles out.

Grid Systems in Graphic Design

Want to go back to the true origins of grids in design? Grid Systems in Graphic Design by Josef Muller-Brockmann is a must read.

While grid usage is a good habit, something has definitely become clear - it's easy to then let bad habits slip back in. Almost like spreading skinny margarine on your toast, but then finishing it off with 5 spoonfuls of particularly sugary jam. Good intentions at the start doesn't quite cut it.

Doesn't have to mean 'divitis'

Applying a grid based class to an element on your page doesn't mean that element has to be a div. This sounds incredibly obvious, but it's surprising how many developers seem to forget about semantic value when adding a grid class reference. Your grid class is only there to bring in the relevant styles to create a column, nothing else. It should have no effect on your choice of HTML usage. You may be defining structure, but ultimately the element will contain content of some description. What kind of content is it? Always consider this question and then produce the correct HTML.

Keep the classes efficient

The CSS of any grid class is nice and lightweight for a reason. You should know exactly what you're getting from them, they're minimal but powerful. Additional classes should never be applied to override any of the widths, padding, or margins that the grid class may be producing. Neither should the grid CSS be duplicated to an extra class (or shoved into an existing class) and modified to fit. If you're creating a grid - stick to the system. A second or third class alongside your grid class should be bringing everything to the party that the grid doesn't.

Semantics

Semantics are important. Grid classes will always slightly disrupt perfect semantic HTML, but avoid awful class names like “col1”, “col2”, or “grid1”, etc. I tend to favour “one-column”, “two-column”, and onwards. At the very least, these classes do essentially describe the structure and size of the element.

Try rolling your own

Using an existing grid system is better than having no column structure at all, but I do worry that it's become the norm for many designers and developers, and that's all they consider. A preset grid should only be used if it truly is the ideal solution for your design.

Attempt to create your own grid. You'll hopefully create something that's a lot more efficient with it's code, and much more suitable for what you're trying to achieve.

And remember, your grid's structure can be as crazy as you want to make it (within reason!). Your columns certainly don't all need to be consistent widths, nor do you need to follow the popular column count of 10 or 12. Again, create what suits you best.

Try display: inline-block

Floats may be suitable for the design your developing, but at the very least, consider the use of display: inline-block instead. I'll simply link you to an article by Joshua Hibbert, who explains it better than I ever could.

Think fluid

In these days of the responsive and 'one' web, try to favour a fluid grid approach over the static alternative. Even if the overall width of the website itself is going to a set figure, as Harry Roberts described brilliantly, every time you hard code a width or height you're making a commitment you might not necessarily want to be making. If anything, fluid/percentage based columns are quicker to calculate and put together. When you're working with pixel widths, you're already using those percentages to work out how many pixels you should be giving each column. So, whether the website as a whole is responsive or not, try to make your grid fluid as a minimum. And again, this leads nicely into my final tip…

box-sizing: border-box

The default CSS box model in all modern browser sucks. When fluid widths and heights come into the equation, it sucks even more. In fact, if CSS didn't allow you to switch the box model via box-sizing, I'd say perfect fluid grids would be nigh on impossible.

To explain - with our default box model, declarations such as padding and borders will be added on to the declared width. So a div with a width of 100px, and padding of 10px would have a total width of 120px. With pixels, I've always found the box model (and the math involved) inconvenient but not impossible. But with percentages, well&hellip

So, we have another div. This time it has a declared width of 40%. Now, to make the math with the default box model feasible, we'll need to add the padding as a percentage also. So, a 5% padding could be added to take the total width of the div to 50%.

Remember, padding is particularly important with website and grid structure, particularly with the spacing and readability of text.

But to be blunt, percentage based padding just doesn't really work.

Declare them in percentages, and 5% worth of padding can vary from 128px in a full browser window on a 27" iMac, or, well, virtually nothing on your average smartphone screen.

Padding percentages could of course be adjusted to match the screen via media queries, but you'll soon find the lines of CSS stacking up, and your headache become a lot more intense…

So, wouldn't a box model where the declared width actually means the full width of the element be awesome?

Well, that's exactly what box-sizing: border-box does. A width: 100% will mean just that, regardless of how much padding or border may be being applied.

Pixels and percentages!

Percentages and pixels in perfect harmony…

So, with our fluid grid, this is where we solve our main problem. Instead of virtually useless percentage set padding, switch back to the pixels (yep, they're still useful for certain elements!). Percentage widths and pixel padding can now work seamlessly together. Whatever size the screen or browser window may be, pixels are as consistent as you'll get. 20px worth of padding will work nicely on anything.

Ultimately, switching the box model just works better for everything. Hence, as Paul Irish recently encouraged, this line has become a key part of my reset…

* { box-sizing: border-box; }

Now, if you need to support IE6 and IE7, they won't understand a word from "box-sizing" CSS. No problem though, a polyfill exists.

A few browsers require prefixed CSS also, all in Paul's writeup.

Embrace the box model freedom!

Want updates?

Get an email each time I write about design and tech. Zero spam. Or, follow me on Twitter.