Every so often someone declares the grid dead. It never is. What changes is what's doing the counting — a print designer's ruler, a CSS framework's class names, or now, the browser itself, measuring the space a component actually has rather than the width of the screen it happens to sit on.

If you're building or rebuilding a site, the grid is still the first decision that matters. Get it right and everything else — spacing, type scale, image treatment — has somewhere honest to sit. Get it wrong and you'll spend the rest of the project fighting alignment issues that were never really about alignment.

Why 12 columns won

Twelve divides cleanly by two, three, four, and six, which means a 12-column grid can produce halves, thirds, quarters, and sixths without any column ever landing on a fraction. That's the whole reason it became the default: it's the smallest number that gives a designer that much flexibility. A 10-column grid tempts you toward halves and fifths and not much else. A 16-column grid works, but it's more math than most layouts need.

None of that is specific to the web. It's the same logic newspaper designers used a century ago. What the web added was the column gutter as a CSS value instead of a printer's measurement, and, eventually, the ability to let columns resize themselves instead of being manually set at each breakpoint.

A grid isn't a constraint on creativity. It's the thing that lets the rest of the page look intentional instead of accidental.

The breakpoint problem

For most of the last decade, "responsive" meant defining a handful of screen widths — usually somewhere around 480px, 768px, and 1024px — and telling the grid to reflow at each one. It works, but it has a quiet flaw: it assumes a component always has access to the full width of the viewport. That's true for a page layout. It's not true for a card sitting inside a sidebar, a modal, or a CMS block that might get dropped into a narrow column or a wide one depending on the day.

That mismatch is what container queries solve.

Container queries, briefly

A container query lets an element respond to the width of its actual parent container, not the width of the browser window. Practically, that means a card component can define its own responsive rules once, and those rules will hold whether the card ends up in a full-width hero or a 300px sidebar.

.card-container { container-type: inline-size; }

@container (min-width: 480px) {
  .card { grid-template-columns: 1fr 2fr; }
}

This is a genuine shift in how component libraries get built. Instead of designing a card, then a "card in a sidebar" variant, then a "card in a narrow modal" variant, you design one card that knows how to behave anywhere it's placed. Support across modern browsers has been solid since 2023, so at this point there's little reason to avoid it on a new build.

Where the 12-column grid still fits

In practice

We typically start every project on a 12-column base grid with a consistent gutter, then treat container queries as the tool for anything that needs to travel — cards, widgets, embeddable components. The page grid sets the rhythm; the container queries handle the exceptions.

A quick audit for your own site

  1. Open your site at three widths: 375px, 768px, and 1440px. Does content realign cleanly, or do things just shrink?
  2. Find a component that appears in more than one context — a card in a grid and a card in a sidebar, for instance. Does it look designed for both, or does one location feel like an afterthought?
  3. Check your gutters. If spacing between columns changes inconsistently across breakpoints, that's usually a sign the grid was eyeballed rather than defined as a system.

The grid is infrastructure. Nobody visiting a site consciously notices it, which is exactly the point — they notice when it's missing.