Decision
Adopt a ‘gridless’ approach, start from the document’s natural flow, let content dictate container size, and lean on native layout (flexbox, grid, intrinsic sizing) only as needed instead of imposing a rigid column grid.
Alternatives Considered
Standard 12-column grid system
| 👍 Pros | 👎 Cons |
|---|---|
| Familiar to print and product designers Predictable visual rhythm |
Fights the browser’s layout engine Breaks when a user changes font size or zoom Ignores translated copy that runs longer or shorter than the design Assumes a control over rendering the web never gives you |
Framework grid utilities
| 👍 Pros | 👎 Cons |
|---|---|
| Quick to apply Well-documented |
Encodes the same rigid assumptions Inherits the same brittleness across preferences and locales Adds CSS to ship and then override at the edges |
Reasoning
The web is a different medium from print. What you place on a design grid is not necessarily what the user sees: their font size and zoom preferences can push content out of the grid, and translated copy runs shorter or longer than the words you laid out. A rigid grid treats all of this as breakage; native layout treats it as normal and reflows to honor it. Letting content and the browser’s algorithms drive layout is therefore the inclusive choice, the composition bending to the person rather than forcing the person into the composition. The web was built for documents in the first place, so starting from the document’s natural flow means the platform is already doing most of the work; the more your experience flows that way, the fewer rules you have to write and maintain to hold it together.
Why it mattered
Working with the browser instead of against it is the through-line from this decision to how I think about layout everywhere.
All decisions