My CSS layout strategy

Last week, I explained my strategy for writing CSS selectors. Today, I’ll explain how I decide on and design layouts. It isn’t really about grids; it’s about a repeatable way to make layout decisions.

Studying the content

Before I open Sketch to design or Nova to code, I study the content I’m laying out, as it’s crucial to start with the content and not a predefined container. I decide what’s most important on a page, what elements should be grouped, what should attract attention, and what can stay quiet. This research gives me a sense of the hierarchy I need to create and ideas for expressing it through layout.

Choosing the right grid for the job

How do I know which grid to choose? Each grid type brings something different to a design, so my answer depends on several factors. Let’s break that “it depends” down.

People will be familiar with the ubiquitous 12-column grid, which ships with most frameworks and platforms. The familiarity of its 2-up, 3-up, and 4-up components makes twelve columns an obvious choice when working with developers or in teams.

A compound grid is two or more grids of any type—column, modular, symmetrical, and asymmetrical—on one page. They can occupy separate areas or overlap. Compound grids provide more flexibility, and their interplay of two or more grids is often far more interesting than a single grid in isolation.

A modular grid contains rectangles or square units arranged horizontally and vertically, and is fabulous for organising complex content, so it’s puzzling why so few designers use them.

Then, occasionally, there’s no grid at all, for when I want to tell a very particular story.

What’s important to remember is that choosing a grid should be a design decision. There is no default. Different grids create different feelings and behaviours, so selecting the right one is a design decision, not a technical convenience.

Defining a grid

When I’m implementing a grid in HTML and CSS, I typically define it once, regardless of how many times I plan to use it. I keep a handy set of grid column templates in my boilerplate file, including a 12-column grid and a 4+5 compound:

:root {
--grid-12-col: repeat(12, 1fr);
--grid-compound: 2fr 1fr 1fr 2fr 2fr 1fr 1fr 2fr; }

I apply my chosen grid using a single style:

.layout {
display: grid;
grid-template-columns: var(--grid-12-col); }

I also define values for gap sizes, margins, and a maximum width:

:root {
--grid-column-gap: 1.5rem;
--grid-row-gap: 1.5rem;
--grid-margins: 0 auto;
--grid-max: 80rem; }
.layout {
gap: var(--grid-row-gap) var(--grid-column-gap);
margin: var(--grid-margins);
max-inline-size: var(--grid-max); }

Whether I intend to use child elements or subgrid, these styles permeate my entire grid implementation. And by defining grids, gaps, and max-width once using CSS custom properties, every layout across a project inherits consistency without repeating code.

Creating reusable layout permutations

Every layout instance contains either one, two, three or more child elements, usually divisions or other structural HTML elements. I separate my layout concerns into that underlying grid and then define the arrangements of the child elements using data-attributes:

<div class="layout" data-layout="flow">
<div>[…]</div>
<div>[…]</div>
</div>
[data-layout="flow"] > *:nth-child (1) { […] }
[data-layout="flow"] > *:nth-child (2) { […] }

Instead of designing layouts from scratch each time, I sketch and name arrangements of child elements so I can reach for them quickly as I design.

In that last example, I named the arrangement and proportions of the two-column layout “flow.” But how do I decide how to name them? Well, I could derive names based on their appearance, like “flow,” “split,” or “stack.” But I tend to run out of possibilities doing that.

Instead, I could call them after their content or function, with names like “hero” or “gallery.” But what happens when I need the hero’s layout for something different? Of course, I could just name them after the grid tracks they occupy, with names like “1–5,” “5–9,” and “10-13,” but what if I decide to change the underlying grid and those track numbers change? Honestly, I’ve driven myself nuts thinking about this.

What do I do instead? I avoid the problem altogether and name them after cartoon characters on my own website, capital cities in my Layout Love templates, Welsh politicians for Changemakers, and composers for the Academy of Scoring Arts:

[data-layout="bartok"]
[data-layout="beethhoven"]
[data-layout="bizet"]

Yes, I know this naming convention doesn’t reflect the appearance, content, function, or grid tracks, but it helps me think, “I need the Brahms layout for this.”

Should I use a standard naming convention across all my projects? Maybe. But then I wouldn’t be able to amuse myself coming up with names for my projects. Could there even be an industry standard naming convention? Heck, I wrote about that five years ago, twelve years ago, and as far back as 2004.

Deciding between Grid and Flexbox

I don’t have a checklist for when Grid is a better option than Flexbox, or vice versa, but I do have certain criteria when deciding which to use. Generally, when an element needs to be laid out in one dimension—such as a navigation bar or a group of elements—I will use Flexbox. When I need two dimensions, I choose Grid. Sometimes, the choice comes down to something as simple as how I want the last or widowed item to behave, and whether it should maintain the grid layout or flex to fill the available width. If it’s the former, I use Grid. When it’s the latter, I choose Flexbox.

Adding Multi-column layout

Then there are times when I want to introduce columns which don’t necessarily conform to the layout grid. These might be multi-column text in an article or spreading lists across more than one column to maximise my use of available space. This is when a Multi-column layout is ideal, and I use the measure to define column width rather than the underlying grid layout. Multi-column layout gives me freedom to break away from the grid when a story needs a more editorial flow.

A repeatable way to make layout decisions

My layout strategy isn’t really about grids; it’s about a repeatable way to make layout decisions. It starts with content, moves through choosing the right grid for the story I want to tell, and finishes with reusable permutations that help my designs stay consistent.