The State of CSS in 2026
CSS in 2024 was a turning point. CSS in 2026 is the cleanup. Container queries hit Baseline. The :has() selector landed everywhere. color-mix() became boring. And yet — most production codebases I see still write CSS like it's 2019.
This isn't entirely the fault of the developers writing it. The CSS ecosystem moves fast, but the established patterns in design systems and component libraries lag by 2-3 years. The State of CSS 2024 survey showed adoption climbing for the new primitives, but actual usage in shipped products is a different number entirely. Below are the features I think are actually worth adopting right now, and the ones that look good in demos but aren't ready for your team's velocity yet.
Container queries are the most important addition since Flexbox
I haven't written a component-level media query in over a year. Once you internalize that components should care about their own available width and not the viewport's, going back feels like wearing a tie to a coding job. The mental model finally matches how design systems are actually built. @container (min-width: 32rem) on a card means the card just works in a sidebar, in a 3-column grid, in a hero — without any prop drilling, without any `compact` variants. The migration from media queries is a one-week project for a midsize design system if you've already adopted CSS custom properties for spacing tokens, and the resulting reduction in className noise is worth the afternoon spent doing it. Container queries hit Baseline Widely Available in 2024, which means at this point any team still writing media queries for component breakpoints is choosing to. We have a deep dive on container queries if your team is making the migration now.
:has() is powerful and overused
Hot take: most uses of :has() I see in code review should have been a state class. .form:has(input:invalid) is clever, but .form.is-invalid is two characters of JavaScript and doesn't make selector performance the next person's problem. Reach for :has() when the alternative is impossible (parent-of-direct-child styling, sibling state propagation that JS can't easily reach), or when you're working in a static context where toggling a class is genuinely awkward. The browser implementations are good now — Safari 15.4 was the laggard and that ship has long sailed — but selector specificity rules still apply, and a :has() chain three deep is still a code review red flag. We have a guide on the parent selector with the cases where it's genuinely the right tool.
color-mix() + OKLCH made design tokens viable
For years, "design tokens" in CSS meant a CSS custom property with a hex value and a Sass-era function for darken/lighten that didn't really exist. With color-mix(in oklch, var(--brand) 50%, white) you finally get a perceptually uniform mix that doesn't go muddy through gray, and you can do it at runtime, in CSS, with no preprocessor. The OKLCH learning curve is real — most designers don't think in lightness/chroma/hue and the picker UX in tools is still catching up — but the payoff is consistent contrast across an entire palette. The oklch.com playground by Andrey Sitnik is the fastest way to develop intuition. Our modern color guide covers the practical patterns.
View transitions: yes, but stop choreographing every element
The View Transitions API is great for SPAs. Most teams using it are over-engineering their choreography. A simple cross-fade — the default — covers about 80% of "make this feel native" use cases. The moment you start naming individual view-transition-name values for hero images, list items, and a header logo simultaneously, you're inventing a state machine that will break the next time someone refactors a component. Start with cross-fade. Add named transitions only where the storytelling genuinely warrants it. The MDN reference is the canonical starting point.
Anchor positioning: still not safe for production
This one will be unpopular. Anchor positioning is a great spec. It is technically Baseline. But Safari shipped support late and the fallback story for older Safari versions is thorny enough that I'm still recommending Floating UI or popover-based libraries for any project that takes browser support seriously. By 2027 this advice will probably flip. For now: be conservative, especially for anything user-facing where a misaligned tooltip ruins trust. The caniuse data tells the real story — go look at the version history before you ship.
The summary, if you want one: container queries and color-mix() are boringly safe; :has() is sharp, use sparingly; view transitions are great if you don't over-do it; anchor positioning needs another year. Most other "modern CSS" features (@scope, text-wrap: balance, scroll-driven animations) are nice-to-haves that won't change how your codebase is structured. For a broader background, the web.dev Learn CSS course remains the best free curriculum, and MDN's CSS reference remains the canonical lookup.
One more thing worth saying: the gap between what CSS can do and what most teams ship is no longer a "browser support" problem. It's a tooling-and-habits problem. The bundlers ship the new syntax, the browsers run it, the docs are good. What's missing is the willingness to retire patterns that have become muscle memory. If you take one thing from this site, let it be that. Audit one component this week — pick the one that has the most media queries — and see if container queries collapse it. The answer is almost always yes.