Rethinking the Grid

At Shopify, we’re rebuilding much of our front-end code for Shopify Admin. This is giving us the opportunity to re-evaluate why and how we build things.

One of the first components that we decided to work on was the grid.

24 Column Grid

Shopify has, for at least the last two and a half years that I’ve worked there, a 24 column, percentage-based grid. This type of grid is quite common in the industry and one that many designers like.

As we talked about what our new grid system should be, some designers on our team pushed to keep the 24 column grid that we already had. Predictable, flexible, and familiar.

Code Audits

I did an audit of how many of those twenty-four span classes were being used and perhaps unsurprisingly, a fourth of them were unused.

Another fourth of the classes were used only a handful of times.

These types of code audits are very useful because they help reveal opportunities for optimization.

I’m not a fan of creating code on the off-chance that it might be used someday. The code audit revealed that we could lighten our load.

Making it easier for everybody

One of the goals was to have a system that was easy for designers and developers alike. If a new cell is added in a row, the design shouldn’t just fall apart.

Looking at the design, we noticed that most of the time, we just needed cells of equal width.

With Shopify Admin, our browser support is kept to modern browsers and with that came quick consensus among the team: “let’s try flexbox!”

We let flex-grow do its magic. Cells become equal width and new cells can be added without breaking the design.

.grid { display: flex; }
.grid__cell { flex: 1; }

Not every row is going to have equal width cells, though, and this is where we ran into some contention on the team.

My original proposal was to use flex-grow to achieve cells of different weights. flex-grow: 2 in a row of 3 cells would produce one cell at 50% width and the others at 25%.

This had a couple limitations, though:

It didn’t allow a lone cell in a row to be less than 100%, andpadding throws off cell calculations for which box-sizing doesn’t help. (`flex-basis` solves the padding issue.)

We decided to augment our system with a few percentage-based classes: .grid__cell--half, --third, --quarter, and --fifth. This solved the two limitations we had with the previous approach and works well with the default .grid__cell.

.grid__cell--half { flex: 0 0 50%; }
.grid__cell--third { flex: 0 0 33.333%; }
.grid__cell--quarter { flex: 0 0 25%; }
.grid__cell--fifth { flex: 0 0 20%; }

What’s next

We’ve created the grid but have yet to roll it out across the site—and deal with any of the unforeseen issues that may come out of this approach.

Right now, it looks like flexbox will give us a flexible (pun unintended) system with less code. That’s a win-win.