30 Tailwind CSS Grid Layouts

Reach for an intrinsic track definition instead of breakpoints. The integrations directory (demo 11) and the photo gallery (demo 03) both use one arbitrary utility: grid-cols-[repeat(auto-fill,minmax(220px,1fr))]. The minmax(220px,1fr) says every column is at least 220px, and shares leftover space equally; auto-fill asks the grid to lay down as many of those tracks as the container can hold. At 1400px you get six columns, at 700px three, at 360px one — and the card content never has to know. Add gap-4 for the gutters. The one thing to get right is the min value: pick the narrowest a card can be before its text looks cramped, not the width you want on desktop. Because the tracks are computed from the container, this keeps working inside a sidebar, a modal or a dashboard cell with zero extra classes.

Both create as many minmax() tracks as fit, but they treat the empty tail differently. With auto-fill the grid keeps the extra empty tracks at their minimum width, so a row of three cards stays card-sized with blank space on the right. With auto-fit those empty tracks collapse to zero and the 1fr flexible maximum lets the surviving cards absorb all the leftover width — which is exactly your giant-column bug. Two items in a wide container each balloon to half the row. The fix is to decide intent: if items should grow to fill the row, keep auto-fit; if they should stay a fixed size and leave a gap, switch to auto-fill. The gallery grids here use auto-fill so a half-empty last row reads as a grid, not two stretched banners. Nothing else in the class list changes.

They use subgrid. Demos 15 and 17 make each card a grid item that also becomes a grid, inheriting the parent's row lines with grid-rows-subgrid and spanning the rows it needs (row-span-4 on the card). Now the title row, the description row and the button row are shared tracks across all cards, not private to each. A card with a two-line title and a card with a four-line description still place their button in the same shared final row, so every CTA lands on one baseline regardless of content length. Without subgrid you would be reaching for equal-height hacks or a fixed min-height that breaks the moment copy grows. The gotcha: the card must span the exact number of rows the parent defines, and the parent needs those rows declared (grid-rows-[auto_auto_1fr_auto]) so the 1fr soaks up the slack and pins the button down.

Because grid-auto-flow-dense (demo 24) and span-driven mosaics (demo 23) reorder the visual placement to backfill holes, but the DOM order — which is what focus and a screen reader follow — never moves. A tile that visually sits fourth may still be tenth in source, so Tab order and reading order diverge from what the eye sees. This is a genuine WCAG concern (meaningful sequence), not cosmetic. The rule the collection follows: only use dense packing when the order is not meaningful — a decorative photo wall or an asset library where any order is fine. For anything ordered (steps, a ranked list, a table), keep the natural flow and accept the occasional gap. Never use CSS order or dense packing to fake a sequence, and don't rely on it to move a call-to-action earlier — put it earlier in the markup instead.

That is a container query, and it is the whole point of demo 20. The teaser's wrapper is marked @container, and the card's internal grid keys off the card's own width with container variants like @md:grid-cols-[200px_1fr]. Dropped into a wide main column the card is wider than the threshold, so it goes horizontal — image left, text right. Dropped into a narrow sidebar the same component falls back to a single stacked column, with no change to its markup or props. Media queries can't do this: they only know the browser width, so the identical card would render the same in both slots. The setup cost is two things — a parent that establishes containment (@container) and children that use the @-prefixed variants rather than sm:/md:. Reuse the teaser anywhere and it adapts to its actual space.

Yes, and demo 30 is the extreme case: a real 18-column table where hydrogen sits at column 1 and helium jumps to column 18 on the same row. The parent is grid-cols-18, and each cell uses explicit line placement — col-start-1 for hydrogen, col-start-18 for helium — so the gap between them is real empty grid, not a spacer element. The status map (demo 28) does the same trick with col-start/row-start to drop coordinate pins onto a graticule. The mechanism is that CSS grid lets any item name the line it begins and ends on, independent of source order, so you place items by coordinate rather than by flow. The one caution: coordinate placement is precise but not fluid — a fixed 18-column grid needs a horizontal scroll container on narrow screens, which is why the table wraps in an overflow region rather than trying to reflow chemistry.

Two different tools for two different needs. The help center (demo 07) uses genuinely fixed rails — a 170px category column that never moves — by giving the grid fixed side tracks (grid-cols-[170px_1fr_220px]) and letting only the centre track's content scroll. The docs page (demo 02) instead uses sticky top-0 (or a small offset) on the on-this-page rail, so it scrolls with the article until it reaches the top of the viewport, then pins. Sticky is usually what you want for a TOC because it releases at the end of the content instead of overlapping the footer. The classic bug: sticky silently does nothing if any ancestor has overflow-hidden or overflow-auto, because that ancestor becomes the scroll container and the element sticks to it instead of the page. Keep the sticky element's scroll ancestor clean and give it a defined top.

Grid earns its keep when you control both axes at once: dashboards (demo 16), the 12-column marketing system (demo 08), coordinate placement (demos 28, 30) and any subgrid alignment. Reach for something simpler when you don't. A single row or column that just needs items to wrap and space out — a logo wall's fallback, a tag list, a button group — is cleaner as flexbox, because grid's track machinery is overhead you never use. Long-form prose (demo 01) is really one measured column; a max-width block beats a one-column grid. And a truly staggered height masonry, where items pack vertically by shortest column, still isn't grid's strength unless you accept the reading-order tradeoff above — a dedicated masonry approach or columns may serve better. The test: if you're only positioning along one axis, or fighting the grid to reorder for accessibility, you probably want flex or block instead.