CSS in 2026:

By Jared Lyvers, ldnddev — March 13, 2026

For a long time, the division between CSS and JavaScript was pretty clear. CSS handles how things look. JavaScript handles how things behave. If you wanted a tooltip, a popover, an animated page transition, or a masonry layout, you reached for a library. That was just how it worked.

In 2026, that line has moved significantly. A wave of new CSS features — some just landing in browsers, some finally getting broad support — can handle interactions and layout patterns that used to require JavaScript. And we're not talking about minor cosmetic stuff. We're talking about features that reduce page weight, eliminate layout shift, and cut the number of dependencies you ship to your users.

Here's what's actually worth paying attention to, and what it means for how we build sites today.

CSS Anchor Positioning: Tooltips and Popovers Without the Library

If you've ever built a tooltip, dropdown menu, or popover, you know the pain. You bring in Popper.js or Floating UI, write positioning logic, handle edge cases for when the tooltip hits the viewport boundary, and pray nothing breaks on mobile. It works, but it's heavy and fiddly.

CSS Anchor Positioning changes the equation. With anchor-name on a reference element and position-anchor on a floating element, you can tether one element to another entirely in CSS. The browser handles the spatial math. You can even define fallback positions with position-try — so if the tooltip would overflow the viewport, it flips automatically.

Combined with the native Popover API (which handles open/close state with zero JavaScript for simple cases), you can now build fully functional, accessible tooltip and popover components with nothing but HTML attributes and CSS. For projects where we're trying to minimize JS payload — especially Drupal and WordPress sites that are already carrying a fair amount of frontend weight — this is a real win.

Browser support as of early 2026: Chrome and Edge have shipped it; Firefox and Safari support is rolling in. Worth checking caniuse.com before using in production, but the trajectory is solid.

CSS if() Function: Conditional Styling Without JavaScript

This one is genuinely new. The CSS if() function — shipping in Chrome now and working through the standards process — lets you write conditional logic directly in CSS. Think of it like a ternary operator for style values.

The syntax looks like this:

color: if(style(--variant: primary): white; else: black);

In practice, this means you can conditionally apply styles based on custom property values without writing media queries, without extra utility classes, and without JavaScript toggling class names. Component variants, theme-aware styles, and state-driven appearance changes all become more self-contained.

For teams building component libraries or design systems — something we do frequently for clients running custom Drupal or WordPress themes — this reduces the cognitive overhead of managing all the conditional styling logic that normally ends up scattered across JavaScript and CSS both. It keeps style decisions where they belong: in the stylesheet.

It's worth noting that if() is still early. Support is limited to Chrome at the moment, with Firefox and Safari working toward it. Use it progressively — define sensible fallbacks and layer the enhancement on top.

Native CSS Masonry Layout

Masonry layouts — think Pinterest-style grids where items pack tightly together regardless of varying heights — have been a JavaScript tax for years. You either reach for Masonry.js, write your own column-packing logic, or use a CSS-only column hack that breaks down on reorder or filtering.

Native CSS masonry support is now in browser previews and moving toward stable release. The syntax is clean:

display: grid;
      grid-template-columns: repeat(3, 1fr);
      grid-template-rows: masonry;

The browser handles the packing. No JavaScript. No layout shift from script-calculated positions. No dependency to maintain. For portfolio sites, blog grids, or any content-heavy layout where items have variable height, this is a meaningful upgrade over what we had before.

The performance benefit is real too — browser-native layout runs significantly faster than JavaScript-calculated equivalents, particularly on lower-end mobile devices. For clients where page performance is a priority (which, for SEO reasons, it always is), that matters.

Scroll-Driven Animations

Scroll-based animations have been a JavaScript staple for years — Intersection Observer, scroll event listeners, GSAP ScrollTrigger. They work, but they run off the main thread with varying results, add JS payload, and can introduce jank if not carefully optimized.

CSS scroll-driven animations change this with two new at-rules: @scroll-timeline and the animation-timeline property. You can now tie animation progress directly to scroll position or element visibility — entirely in CSS, with the browser doing the heavy lifting off the main thread.

Fade-in elements on scroll, parallax-style effects, progress indicators tied to scroll position — all doable now without JavaScript. Browser support is good across Chrome and Edge, with Firefox support landed as well. Safari is the holdout, as usual, but the feature degrades gracefully.

For marketing sites and landing pages — exactly the kind of projects we build regularly — this replaces one of the most common JavaScript patterns with something lighter, faster, and easier to maintain.

@scope: Scoped Styles Without a Build Tool

If you've worked on a large Drupal or WordPress project, you know the CSS specificity mess that builds up over time. Styles bleed between components. A rule written for one part of the page breaks something three templates away. You either fight it with increasingly specific selectors, introduce a shadow DOM solution, or just add more !important and hope for the best.

The CSS @scope rule offers a native solution. It lets you define a styling boundary so that rules inside the scope only apply to elements within a specific subtree:

@scope (.card) {
        h2 { font-size: 1.25rem; }
        p { color: var(--text-muted); }
      }

The styles in that block only apply to h2 and p elements inside a .card. Nothing leaks out. You get component-level encapsulation without a JavaScript framework, without CSS modules, and without a build step.

For teams building component-based themes in Drupal or WordPress — which describes most of our client work — this is a cleaner alternative to the BEM class naming conventions or framework-specific scoping mechanisms we've been relying on. It's native, it's readable, and it reduces the amount of specificity management you have to do manually.

View Transitions: Page Changes That Don't Feel Broken

One of the things single-page apps got right was smooth page transitions. When you navigate between routes in a React or Vue app, the UI can animate between states instead of doing a jarring full-page reload. Multi-page sites never had a good answer for this — until now.

The View Transitions API lets you animate between page states — including full page navigations in multi-page apps — with a few lines of CSS and a small amount of JavaScript to trigger the transition. You can cross-fade, slide, or build custom animations between pages without converting your site to an SPA.

For our clients, this is valuable for two reasons. First, it improves the perceived performance of navigating through a site — users experience transitions as faster even if the actual load time is the same. Second, it keeps the architecture simple. You don't need a JavaScript router or a framework to get smooth page transitions anymore. A Drupal site or a WordPress site can have this with minimal effort.

Chrome has shipped full cross-document view transition support. Firefox and Safari are working toward it. Like most of the features on this list, it degrades gracefully — browsers that don't support it just do a normal navigation.

What This Means for How We Build

Taken together, these features represent a significant shift in what CSS can do on its own. Positioning, conditional logic, masonry layouts, scroll animations, style scoping, page transitions — a year ago, most of these required a library or a custom JavaScript implementation. Today, the browser handles them natively.

That doesn't mean JavaScript is going anywhere. Complex application logic, data fetching, dynamic state management — JavaScript still owns all of that. But the amount of JavaScript we need to ship for UI behavior is shrinking, and that's good for everyone. Less JavaScript means faster initial load, less to debug, fewer dependencies to update, and simpler codebases to maintain.

At ldnddev, we've started auditing our standard component toolkit to identify where we can swap JavaScript-driven behavior for these native CSS alternatives. Not everywhere at once — browser support still requires judgment on a per-project basis — but progressively, as support matures.

If you're building a new site or planning a significant rebuild, now is a good time to factor these in. The browser is doing more than it used to. Let it.

Until next time, Jared Lyvers