The most important part of your CSS

Published 18/06/2015

There is a bit of CSS that you will write or more likely use from a library that will influence your whole project. It is crucial and it’s quality and adequacy can make or break your productivity as you develop. That CSS is famous (or infamous!) grid.

Laying out things on the web has always been a struggle. You only have to dive into HTML email to see how terrible it was because table layouts are still a thing there. As graphic design practices trickled through to the web and tables were starting to get filled with data instead of layouts, some people discovered that we could abstract some of that CSS into grid systems. And rightfully so - controlling width is one of the most used CSS properties. It was, all in all, a great success. Our grids maybe were not as advanced as in traditional graphic design, but they were a fantastic abstraction that saved us a lot of time.

Then came along responsive design. It demanded a lot more from our humble grid. But as older, buggy browsers were pushed out and using things like box-sizing, inline-block and negative margins became common (and reliable), the grid adapted.

It’s quite trivial to write a grid these days; but it’s not trivial to know when to use inline-block or floats. It’s not trivial to polyfill our good ‘ol grid with flexbox either. Twitter’s Bootstrap grid might not be ideal for your project; you’ll know it when you are going to have to change it all the time. The breaking point will come when you will not use the grid because you will be afraid of the side effects that can cause and you will make little, impromptu, error-prone grids on the spot.

All this should tell you one thing: the grid needs special attention from the developer, from the outset. You can see this by the emergence of tools like Gridset and efforts on bringing the cassowary constraint solver to the web. On most projects, laying out is a massive part of writing HTML & CSS. The better your tools and your understanding of them, the smaller your headaches later.

So what should you do when assessing a grid? Some key points should be:
- how can you safely extend the grid? (ie. what do you do if you need different gutters somewhere down the line?) - what are the limitations of the grid (ie. how many columns can we have? Can the grid be used in any container? Is there some patterns that should be avoided) - does it use floats, inline-block (do we need to care about extra white space), flexbox, something else? - how is responsiveness handled? how can it be extended? - will it work with other frameworks that we are using? - how does it fit into the naming scheme used for our CSS? - what browsers does it support?

If you create your own, setup a test page and run it through Browserstack or similar. Make sure your new rad idea works across the browsers you want consistently. The big benefit of doing this is that you don’t have to settle for the general case of the grid, you can make allowances that your project requires.

Realising the above, I’ve created a library that lets you create grids on demand called Taco Grids. Currently written for the Stylus CSS preprocessor, it’s an experiment in using a flexible tool for creating easily extensible grids. You can read a bit more about Taco in my previous blog post or jump to it's home page to look at the docs and example usage.