CSS

An early look at CSS Grid before we use it in production

CSS

CSS Grid shipped in Chrome, Firefox, Safari, and Edge earlier this year, and we have spent some internal time experimenting with it before bringing it into client work. Where flexbox is fundamentally one-dimensional — a row or a column — Grid lets us define an actual two-dimensional layout, rows and columns together, directly in CSS.

The layout problem that made the case for us

The use case that sold us was a magazine-style content layout for a media client's homepage, with articles of different sizes arranged in an irregular grid — a large featured story spanning two columns and two rows, smaller stories filling in around it, all needing to reflow sensibly at narrower viewport widths. We had been faking this with a mix of flexbox and manually calculated widths, which worked but required careful, fragile math any time the number or mix of story sizes changed, and broke in subtle ways whenever an editor's chosen story lineup did not match the exact combination the layout had been tuned for.

What Grid actually simplifies

With Grid, the same layout is a handful of lines defining `grid-template-columns` and `grid-template-areas`, with each content block assigned to a named area rather than positioned through accumulated width and margin calculations. Renaming which areas exist at a given breakpoint, to rearrange the layout for tablet or mobile, is a matter of redefining `grid-template-areas` in a media query — the DOM order and the actual markup never need to change, only which named region each area occupies at that breakpoint.

  • `grid-template-areas` gives us a literal, readable ASCII-art-like representation of the layout directly in the CSS, which has turned out to be a genuinely good communication tool in code review — a reviewer can see the layout's shape without opening a browser
  • `fr` units solve a class of proportional-sizing problem that used to require percentage math with gaps and gutters subtracted out by hand
  • `grid-gap` (as it was called at the time) replaced a surprising amount of margin-based spacing hackery that previously required removing the last item's margin as a special case

Where we are being cautious

We are holding off on shipping it broadly until we are comfortable with fallback behavior for the handful of older browsers some clients still need to support, since Grid's practical support was only just becoming solid this year and a handful of the older Android and Internet Explorer users some of our clients' analytics still show in meaningful numbers would see a broken or empty layout without a deliberate fallback strategy — `@supports` feature queries can gate a Grid-based layout behind a simpler flexbox fallback, but building and testing that fallback path doubles the layout work for now.

We also noticed the DevTools support for visualizing and debugging Grid layouts is still maturing across browsers, which makes troubleshooting a misbehaving Grid layout slower than the equivalent flexbox debugging we are used to, since we cannot yet reliably overlay the grid lines and named areas visually in every browser we test against.

What is next

For internal tools and greenfield projects with modern browser requirements, expect to see more Grid from us next year, once browser support and our own team's fluency with the spec's less common features — subgrid is not yet supported anywhere and will presumably take a while — have matured further. We are treating this year as the deliberate learning phase before Grid becomes a default the way flexbox already has, rather than rushing it into client-facing work before we have fully internalized both its capabilities and its current rough edges.

← Back to the journal

Have a project in mind?
Let’s talk.

Tell us where you are and where you want to go. We'll map the fastest route between the two.

Currently accepting new clients