Modern CSS you should actually be using

CSS has moved fast over the last two years. Browser support has caught up with features that used to require workarounds or JavaScript. These are the three I reach for most often now.

Container queries replace most media query hacks

Media queries respond to the viewport. Container queries respond to the parent element. That's the distinction that matters.

A card component that needs to reflow when it's in a narrow sidebar (not when the viewport is narrow, but when the container is narrow) is exactly what container queries are for:

.card-wrapper {
  container-type: inline-size;
}
 
.card {
  display: grid;
  grid-template-columns: 1fr;
}
 
@container (min-width: 400px) {
  .card {
    grid-template-columns: 120px 1fr;
  }
}

The card reflows based on its own space, not the screen size. This is the right mental model for component-driven UI. I've removed a lot of JavaScript resize observers since this landed in all major browsers.

This site leans on it in the Lab: every experiment there runs at three different widths, full page, half the index grid and a third of the homepage strip, so the demos size themselves against their container rather than the viewport. A media query cannot see that difference at all.

Cascade layers give specificity back to you

Specificity fights are the main reason CSS gets hard to maintain. !important starts appearing. Selectors get more specific to override other specific selectors. The cascade becomes a liability.

Cascade layers let you declare an explicit specificity order:

@layer base, components, utilities;
 
@layer base {
  a { color: var(--color-link); }
}
 
@layer utilities {
  .text-accent { color: var(--accent); }
}

Utilities always win over base styles regardless of selector specificity, because the layer order says so. You can override anything from the base layer without touching it. This is the pattern I use in every new project now; it keeps the design system predictable.

Logical properties for internationalisation you didn't plan for

margin-left and padding-right are physical. margin-inline-start and padding-inline-end are logical: they respond to writing direction. If a site ever needs right-to-left language support, physical properties require a full audit. Logical properties just work.

/* Before */
.card { padding-left: 1rem; margin-right: auto; }
 
/* After */
.card { padding-inline-start: 1rem; margin-inline-end: auto; }

I've made this switch in my base styles. The visual output is identical for LTR English. The code is future-proof.

Two more that are nearly there

The three above are safe everywhere today. Two others are worth learning now, because they remove a category of JavaScript rather than a few lines of it.

@property lets you register a custom property with a type, which is what makes it interpolate. Transition an unregistered custom property and you get a jump at the halfway point, because there is no defined way to tween two unknown strings. This is the single most common reason a CSS-only effect "doesn't animate" when it looks like it should. There is a worked example in the duotone image reveal, where registering one percentage is the difference between the effect growing and snapping.

Scroll-driven animations go further: animation-timeline: scroll() drives keyframes from scroll position instead of from time, so the animation runs where scroll runs and cannot fall behind a busy main thread. Safari and Firefox have not shipped it yet, so it still needs a fallback, which is exactly what the scroll-driven progress ring documents.

The bigger picture

None of these require a build step, a framework, or a dependency. They're CSS features that work in every modern browser today. The cost is learning the syntax; the payoff is simpler, more robust stylesheets.

The best CSS is still the CSS you didn't write. But when you do write it, these are the tools that earn their keep.