Modern CSS You Can Actually Ship in 2026

Modern CSS is no longer a choice between exciting demos and conservative production code. Several features that once needed JavaScript or awkward layout workarounds are ready for everyday use. The important distinction in 2026 is not whether a feature is new, but whether an unsupported browser can still receive a complete, usable page.

Ship :has() without a compatibility detour

The relational :has() selector is Baseline Widely available. It is a practical way to style a component according to its contents or state without adding a class from JavaScript. For example, a form can highlight a field group containing an invalid control:

.field-group:has(input:invalid) {
  border-color: crimson;
}

No @supports guard is required for normal production use. Still, keep a plain rule first when the style is optional. If a browser cannot parse a selector containing :has(), it drops that rule; it does not damage the rest of the stylesheet. Use :is() or :where() when a forgiving selector list makes sense.

Make components responsive with container queries

Size container queries are also Baseline Widely available and are usually a better fit than viewport media queries for reusable cards, sidebars, and embedded widgets. The component responds to the space it actually receives:

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

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

A media-query fallback can sit beside the @container rule. Unsupported @container blocks are skipped safely, so the fallback remains active. Be more cautious with newer container style queries, scroll-state queries, and anchored container queries: treat those as progressive enhancements rather than assuming that every container feature has the same support profile.

Treat view transitions as polish, not navigation

The View Transitions API is Baseline Newly available, not yet Baseline Widely available. It can make same-document or cross-document navigation feel smoother, but a transition must never be the thing that makes navigation understandable or usable. Older browser versions simply need to render the page normally.

For JavaScript-driven transitions, feature-detect the API before calling it:

if (document.startViewTransition) {
  document.startViewTransition(updatePage);
} else {
  updatePage();
}

For cross-document transitions, unsupported browsers ignore the @view-transition at-rule. Keep the normal link, focus behavior, loading state, and final page independent of the animation. If the effect disappears, the product should still feel complete.

Keep a real fallback for native masonry

Native masonry is the feature that still deserves a hard stop before adoption. The current grid-lanes syntax has Limited availability and remains experimental; stable support is not broad enough to make it the only layout path. Wrap it in @supports and provide a conventional grid fallback:

.gallery {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(14rem, 1fr));
  gap: 1rem;
}

@supports (display: grid-lanes) {
  .gallery {
    display: grid-lanes;
    grid-template-columns: repeat(3, 1fr);
  }
}

The fallback should be more than a placeholder. Check reading order, keyboard flow, image sizing, and the behavior when cards have very different heights. A multi-column or JavaScript solution may be appropriate for a specific design, but none should be introduced merely to chase a visual effect.

A safe default for 2026

Use :has() and size container queries directly when they simplify the component and the unsupported behavior is naturally harmless. Add view transitions only as progressive enhancement, with feature detection in JavaScript where applicable. Keep masonry behind @supports until its support profile is broad enough for your audience. This approach lets modern CSS reduce complexity without making browser support the user’s problem.

Further reading: MDN’s :has() reference, container queries, the View Transitions API, and masonry layout.