“Which grid system do you use?”
For whatever reason, this question pops up all the time. I don’t think it’s a particularly useful question, though. It seems like there’s another question just beneath the surface of this one: “Which grid system should I use?” No one grid system is going to be appropriate for every situation. Because of this, the answer to both these questions will always be the same: a big fat, “It depends.” See? Not useful.
What’s more important than which specific grid system is being used is the kind of grid system that’s being used. There are dozens of grid systems out there, and frankly, I don’t have time to try them all out and review them. But here’s the good news: there are only a few kinds of grid systems.
Actually, to put a number on it, there are three kinds of grid systems:
Semantic grid systems
Class-based grid systems
Homebrewed grid systems
When grid systems are grouped like this, it makes them much easier to talk about. You can narrow down what kind of grid system you need, then take your pick from there. Much more useful than, “It depends.”
Semantic Grid Systems
Notable examples:
Semantic grid systems are used by applying mixins to selectors of your choosing. These mixins render out rules to set proper widths, clearing, and any other needed styles. They’ll also take care of that math you’ve forgotten from grade school. In effect, you get the benefits of using a grid system without cluttering your markup with presentation-related classes. No library overhead is added either, since CSS is only rendered when mixins are used. And all semantic grid systems start with the letter S for some reason.
All semantic grid system-related business happens within the confines of the presentation layer. Since semantic grid systems weren’t possible until the advent of CSS preprocessors, most semantic grid systems are built with responsive in mind. To make a semantic grid respond, nest those mixins within media queries. Because of this, you’re not limited to site-wide breakpoints. If you aren’t constrained to site-wide breakpoints, you’re free to tailor your layout changes to something that works with your content. This will ensure your layout will look excellent at all viewport widths. Even those of devices that don’t exist yet. Or at any of the 288 possible widths between 480px and 768px.
I can’t talk about semantic grid systems without complaining about what we call them. It’s a little silly to call them “semantic” grid systems. When we phrase it this way, it implies that using a semantic grid system will somehow make your HTML more semantically juicy. This feels like a marketing move, and isn’t true in the least. Semantic grid systems help keep our HTML free of presentational styles, but they don’t imbue our web pages with any additional meaning. Since all the “gridness” is provided by mixins, I prefer to call these types of grid systems “mixin-based grid systems.”
Class-Based Grid Systems
Notable examples:
Class-based grid systems are used by applying given classes to the elements you’d like to align in a grid. Typically, the class names provided by these grid systems have the proportions directly in the class name. For example, the class name .grid-item-1-4 might make an element one fourth the width of its parent, or 25% in width.
Even though class-based grid systems have been around for a while, they have evolved to accomodate responsive needs. This is usually accomplished by adding a flag to our class, denoting that a grid item’s proportions shouldn’t take effect until a given breakpoint, in a mobile-first fashion. For example, if we want our grid item to be one fourth in width at small viewport sizes, then jump down to one fifth width at large viewport sizes, we could apply the classes .grid-item-1-4 and .grid-item-lg-1-5 to an element. It might look bulky (because it is), but specifying grid widths in this way packs a whole lot of meaning directly into your element. I’d even argue that you can infer more about a grid by looking at these classes rather than the classes you’d write when using a semantic grid system. Who’s the “semantic” grid system now?
When using a class-based grid system, you’re sprinkling some presentational information into your markup, which is not the place that presentational information belongs. But this alone isn’t a reason to turn up your nose from a class-based grid system. Ask yourself why this could potentially be a problem for your project. If you can come up with a good reason, then this is a mark against class-based grid systems. If you can’t, then don’t sweat it.
I hope you’re worried about performance right now. When a grid system is class-based, CSS declarations need to be written for every possible proportion a grid item could be, multiplied by the number of grid breakpoints you need. Yikes. That sounds pretty bad. How bad, though? That’s going to depend on the specific grid system and the specific project. Keep in mind that CSS declarations for grid systems are very repetitive, so they’ll compress well. For reference, the Pure.css grid system is reported to be 0.8KB. It’s surprisingly simple to test exactly how well it’ll compress, so you should do a little science before taking my anecdotal advice. This brings up a drawback of class-based grid systems: the more grid breakpoints you have, the larger your CSS will be. This makes class-based grid systems more suited to fewer site-wide breakpoints, meaning you’ll be handling small tweaks in layout in your modules’ CSS rather than with your grid.
A huge strength of class-based grid systems is the ability to rapidly put together new grids without touching your CSS. Since the system is already there, you don’t need to name anything, either. This is conducive to building out many different page types with many different layouts. And now other developers (who you may not trust to name things) are empowered to take advantage of the grid system and make adjustments if necessary. Also, trying out new ideas in the inspector is a breeze. You can assemble entire responsive grids in your browser simply by editing some classes. It can come in handy.
Homebrewed Grid Systems
One of the greatest benefits to using a grid system is the nudge to separate page layout from your site’s modules. But you don’t need a formalized grid system to do this. Only a little bit of foresight. If you’re already making this separation, you’re already reaping the biggest benefit of using a grid system. Good for you!
Not using an official grid system is a perfectly viable option. It’ll save you the dependency and learning curve of using a mixin-based grid system, and you won’t ever be sending the overhead of a class-based grid system over the wire to your users. Without a pre-baked grid system, you’re free to write layout styles in any way you see fit. You should, however, think about what kind of classes you’re going to be using to attach grid styles to elements.
Will you be using content-based class names, as encouraged by mixin-based grid systems? Or will you come up with a more reusable system, as seen in class-based grid systems? Whenever you write a class for your zany, homebrewed grid system, each individual class name should deliberately fall into one of these two categories. Your homebrewed grid system’s classes don’t all have to fall in the same bucket, though. You’re allowed to mix and match. In fact, I’ll encourage you to mix and match. Because both these techniques are good at different things.
Although we don’t think of it when we’re using mixin-based or class-based grid systems, using a grid system usually boils down to two distinct use cases: page layout and repeating items.
The page layout use case is the idea of defining proportions for the major elements of your page. “The header is 100%, the main content is 80%, the sidebar is 20%, and the footer is 100%.” That kind of whole-page overview stuff. This kind of stuff is actually really easy to do without a grid system. Using content-based grid classes works well for page layout, since high-level layouts tend to differ between pages, and they are typically difficult to reuse. Class names like .header, .main-content, .sidebar work well here. I recommend adding some sort of prefix to denote that the classes belong to the grid system. Maybe l- for “layout”?
The repeating items use case is the idea of ordering a sequence of items in rows, like an eCommerce site’s product list or a conference’s speaker lineup. Items are equal widths, evenly spaced, and usually in a list of unknown length. While this isn’t quite as simple to pull off as high-level page layout in vanilla CSS, it’s really not all that bad. You can use a couple floats here, a few :nth-child selectors there, and you’ve got a nice-lookin’ grid of repeating items. Cases like this are well-suited for class-based systems. There are more CSS rules to deal with, so code reuse is even more important here. And these lists are usually more generic than high-level page layout, so reusing these grid classes should be more feasible. If your lists are simple, you may be able to get away with simple class names. Like a class of .3-up to denote that grid items should be full-width, then split into thirds at some point. If things get more complex than this, look to class-based grid systems to see how they handle the challenge of multiple breakpoints. You can adopt something similar, tailored to your site.
Ye be warned: established grid systems know what they’re doing. They’re generally very well-tested to get consistent, pixel-perfect results across all browsers. If you’re putting together your own grid system, you won’t have access to this stability. You’ll likely have to fix things up as issues arise while you’re testing your website.
What Kind of Grid System Should I Use?
If you’re designing directly in the browser, using a semantic/mixin-based grid system could be useful to keep your grids consistent and cohesive, all while giving you complete breakpoint flexibility. If your website has lots of different page layouts with varying content, a class-based grid system would let you rapidly build out new templates without even touching your CSS. If you prefer to get your hands dirty and know how things are put together so that you can fix them when they break, maybe you’d want to use a homebrewed grid system. No one grid system is going to be the correct answer for every case, and every person has a different preference in how grid systems should work.
Long story short, it depends.
