Responsive grid systems; a solution?

Written by Harry Roberts on CSS Wizardry.

Grid systems in responsive design are something of a hot topic; a lot of people are trying to solve them but I don’t feel we’re there quite yet.

However! The solution I have devised for inuit.css – I feel – is probably one of the best currently available. In this article I’m going to cover how it works, and the principles behind it.

Before we dive into it, let’s outline some of the problems and requirements we face with responsive grid systems:

• Must have different traits at different sizes because you need to be able to tell a column to be – for example – full-width on narrow devices and half-width on wider ones.
• Must be fluid between breakpoints because we need to cover all bases.
• Must have enough control to decide which columns will transform and at which point because a blanket rule of, say, ‘all half-width columns become full-width at XYZ breakpoint’ are no good; we might want to collapse some but leave others half-width.
• Classes should ideally still make sense at all breakpoints because .span-6 doesn’t make sense when it’s transformed to behave like a .span-12 on narrow screens.

The easy solution to the responsive grid problem might be to make a huge upfront decision. For example, deciding that, at a certain device width, you are going to make all columns halve, and then at the narrowest width you want them all to collapse into full-width columns.

This might work, but is a huge design decision that will likely prove very restrictive. You might not want all your layout to linearise, but a grid system like this would cause it to.

If you’re using Sass, it might be nice to do something like:

.content{
    @extend .span-12;
    @media screen and (min-width:720px){
        @extend .span-6;
    }
    @media screen and (min-width:1200px){
        @extend .span-8;
    }
}

But of course, you currently can’t @extend out of a media query. Where does that leave us?

Taking stock

Sometimes I think we all need to slow down, sit back, look at what we’ve got, and take stock of things. Take things way, way back to basics and start again.

If we redefine our problem, and think on much more simple terms, then we’re looking at this:

I want elements to take on multiple different and conflicting forms at different points.

Basically, we want one thing (a grid column) to be several things (different widths) at different states (breakpoints).

The easiest way to make one thing behave in multiple different ways is, simply, multiple style hooks (i.e. classes). To make one thing behave in a variety of different (and opposing; remember, a grid cannot be full-width and half-width at the same time) ways is to have a separate class for each of those states.

Even with media queries, it is naive to think you can simply, consistently and cleanly make an arbitrary array of things all behave completely differently. If you want a div to have three states then it’s somewhat naive to think you can handle that nicely without three corresponding classes.

We also have to think with some degree of pragmatism; one valiant but misguided attitude a lot of developers seem to have is the desire to be all things to all men. This is admirable, but often counter-intuitive and counter-productive. We need to accept that – when faced with complex problems such as responsive grids – we cannot be everything to everyone.

So, if we act pragmatically and take stock of our situation then we have a much more defined baseline to start building on.

Clean HTML purists, please stick with me!

Building the grid system

In order to combat our .span-12 style of inappropriate classes, we need to think about working with classes like .one-whole, .three-fifths, .five-twelfths and so on. These mean that, instead of spanning x columns, we are now telling a column to take up x percentage of the available width.

What I do with inuit.css is abstract these widths right out and away from the grid system entirely. This means that, although they can be used on the grid system, they are not exclusive to it. The benefit of this is that I could have, say, a photo that I wish to take up half the width of my page: <img src="foo.jpg" alt="" class="one-half">. This would not previously, necessarily, have been possible if they were tied into the grid system too much.

This now means that the grid architecture itself is very slim, just some floats and some clearfixing, as well as some gutter settings.

So, my structural grid stuff lives alone, and the widths merely lay on top of this architecture to provide the sizing.

We still have the problem, however, that .one-half doesn’t make sense if I want to make it a .one-whole at a certain breakpoint…

Defining the breakpoints

The beauty of high-level page layout (i.e. a grid system) is that this is something that is based on device/screen/viewport size.

Grid systems are incredibly high-level scaffolding and page structure, so they will likely only change in the shift between breakpoints (and often devices), for example a layout might typically be linear for mobile (or smallest screens), a little wider for tablet (smaller screens), wider still for desktop (or wider screens).

Using this diagram from none other than Luke Wroblewski we can choose our layout-specific breakpoints as being:

• Palm for things that fit in our hands (like phones).
• Lap for devices that are not handheld, but ‘lap’ devices (like tablets).
• Portable for either of the above.
• Desk for stationary devices (like TVs, PCs etc).

If we accept this generalisation that means we can have multiple width classes like .one-half, .palm-one-half that all live in media queries:

/**
 * Palm-sized devices
 */
@media screen and (min-width:[width of your choosing]){
    .palm-one-whole{
        width:100%;
    }
    ...
}

/**
 * Lap-sized devices
 */
@media screen and (min-width:[width of your choosing]){
    .lap-one-whole{
        width:100%;
    }
    ...
}

And so on…

Now we have a range of classes that only do certain things at certain sizes, tied to our targeted device sizes:

<div class="one-whole  lap-three-fifths  desk-one-half">

N.B. It is widely regarded (and rightly so) that you should not base media queries on device sizes but on ‘what looks best’. This, for the most part, is very true, but we need to think pragmatically. If we want a flexible, recyclable and efficient grid system then we need these absolutes in place.

Because we are writing a grid system to fire at fixed breakpoints it is important to:

1. Make sure the values you use for your breakpoints aren’t based on actual devices (e.g. iPhone in portrait) but are based on numbers that work best.
2. Ensure that your grid remains fluid between breakpoints so that even if it doesn’t reformat, it will still resize.

This all comes back to needing to think pragmatically and not trying to be all things to all people; if we want the ability to rapidly create pages with a responsive grid system then we also have to accept that we need to use concrete values.

Lots of classes in the CSS

A problem you may have noticed is that we are now creating a whole new grid system for each of our breakpoints. Now it’s no longer just .one-whole, .one-half, .one-quarter etc, but one of those classes for every media query we have. Initially this seems like a lot, but…

This level of repetition will compress incredibly well. We all know we should be gzipping our plain text assets anyway, but it’s more important than ever with things like this. Gzip works best on repeated strings, so the more repeated strings in your code then the better compression ratio you will get. Although repetition in code is bad (usually more maintenance, less efficient etc) it’s actually better in terms of compression. Experimenting with the width classes covered in this blog post, I managed to achieve a compression ratio of 81%. This basically means that the compressed size of the classes is actually less than one fifth its original size over the wire. Five breakpoints worth of classes actually compress to less than one uncompressed one on its own.

That all seemed pretty long winded but it’s an important point that needs making; the flexibility a grid system gives us is worth the extra classes if we’re compressing our CSS.

Implementation

Now we’re at a point where we can start building things! We can construct responsive layouts like:

<div class="content  one-whole  desk-three-quarters">
    ...
</div>
<div class="sub-content  one-whole  desk-one-quarter">
    ...
</div>

That’s a very timid example, but you can see how extensible, flexible and reusable that is. It also allows for incredibly quick development, both prototyping and production.

Recap

So, to let that all sink in, let’s go over what we’re doing…

• We have a series of breakpoints for our device classifications (palm, desk etc).
• Each breakpoint’s media query contains its corresponding width classes (e.g. .desk-one-tenth, .palm-two-thirds etc).
• We have the ability to use those classes in our HTML knowing that they only ever work in their respective media query range.

Lots of classes in the HTML?

A lot of people cringe at the thought of so many classes in their HTML, but get this…

Although we can’t @extend out of media queries, we can @extend into them!

That means that instead of having:

<div class="content  one-whole  desk-three-quarters">

You could just have this Sass:

.content{
    @extend .one-whole;
    @extend .desk-three-quarters;
}

Even better, if you use Sass’ silent classes you could use:

.content{
    @extend %one-whole;
    @extend %desk-three-quarters;
}

This means that the classes won’t get rendered into your CSS at all, and you can avoid using them in your HTML! This means that, if you are using Sass and its silent classes, you will have a class available to you for every width at every breakpoint, but they won’t get created until you call them.

Final word

So there we have it, a fully responsive grid system. All the power of an abstracted grid system with responsiveness baked in.

I have bundled all this up into a micro library called csswizardry-grids. Please feel free to try it and use it.

Did this help? We can do way more!