← Back to Blog

Modern CSS in Production: Layout Techniques Worth Adopting Today

For years, building a robust layout meant reaching for a framework, a pile of utility classes, or a JavaScript resize observer to do work the browser simply couldn't do on its own. That era is over. The CSS we ship in production today is genuinely powerful, well-supported across every evergreen browser, and often lets us delete more code than we write. Here are the techniques we lean on daily, and where they earn their keep.

Container Queries: Components That Actually Own Their Layout

Media queries have always had a blind spot — they respond to the viewport, not to the space a component is actually given. A card that looks great in a wide hero looks cramped in a narrow sidebar, even though the screen size is identical. Container queries fix this by letting an element respond to its own container's width.

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

.card {
  display: grid;
  gap: 1rem;
}

@container (min-width: 30rem) {
  .card {
    grid-template-columns: 8rem 1fr;
  }
}

Now the card reflows based on where it lives, not where the browser window happens to be. We build genuinely reusable components this way — drop them anywhere and they adapt themselves.

Subgrid: Aligning Across Nested Layouts

CSS Grid solved two-dimensional layout, but nested grids couldn't share tracks with their parent — so a row of cards with mismatched content lengths would fall out of alignment. Subgrid lets a child inherit its parent's grid lines.

.cards {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  gap: 1.5rem;
}

.card {
  display: grid;
  grid-row: span 3;
  grid-template-rows: subgrid;
}

With grid-template-rows: subgrid, every card's title, body, and footer line up perfectly across the row regardless of how much text each one holds. Before this, we faked it with fixed heights or JavaScript measurement. Now it's one declaration.

The :has() Selector: A Parent Selector at Last

The long-requested "parent selector" arrived as :has(), and it quietly removes an enormous amount of conditional class-toggling from our JavaScript. We can now style an element based on what it contains or what state its children are in.

/* Style a form field group when its input is invalid */
.field:has(input:invalid) {
  border-color: #e5484d;
}

/* Give a card extra padding only when it contains an image */
.card:has(img) {
  padding-block-start: 0;
}

This is one of those features that changes how we think. Interaction states, layout variants, and validation styling that once required a script now live entirely in the stylesheet, closer to the markup they describe.

Cascade Layers: Taming Specificity

On larger projects, specificity wars are a real maintenance cost — a stray !important here, an over-qualified selector there. Cascade layers let us declare the order of precedence explicitly, independent of specificity.

@layer reset, base, components, utilities;

@layer components {
  .button { background: #2563eb; }
}

@layer utilities {
  .bg-transparent { background: transparent; }
}

Anything in utilities beats anything in components, no matter how the selectors are written. It gives large codebases a predictable structure that new team members can reason about instantly.

A Few More We Reach For

• Logical properties — margin-inline, padding-block, and friends make internationalization and right-to-left support close to automatic.
• clamp() for fluid type — font-size: clamp(1rem, 0.5rem + 2vw, 1.5rem) scales smoothly without a single breakpoint.
• aspect-ratio — reserves space for media and kills layout shift with one line instead of the old padding-hack.
• gap in flexbox — consistent spacing without margin cleanup on the last child.

Why This Matters for the Products We Build

None of these are experimental. They ship in every current version of Chrome, Firefox, Safari, and Edge, and they let us build interfaces that are lighter, more resilient, and cheaper to maintain than the framework-heavy approaches many teams are still carrying. Less JavaScript running in the browser means faster pages and fewer moving parts to break. That's a better experience for users and a smaller surface area for us to support over the long haul.

If you're wondering whether your current front end is leaving performance or maintainability on the table, we'd be glad to take a look. Get in touch and let's talk about what a modern CSS foundation could do for your project.