Author
I’ve been keeping an eye on CSS developments recently, partly because we’re in an interesting period where things that seemed impossible a few years ago are quietly landing in browsers.
And partly because I’m curious whether we’ve reached the point where we can genuinely reduce our JavaScript dependencies without making life harder for ourselves.
The short answer? We’re getting there. Though whether that’s entirely a good thing is another debate for another time.
The if() function: Because apparently stylesheets can now think
Browser support: Chrome/Edge 137+, Safari & Firefox: Not yet supported
The CSS Conditional Values Module has introduced an inline if() function, which is… well, it’s quite something. Instead of writing multiple media queries to handle a button’s appearance, you can now do this:
button {
background: if(prefers-color-scheme(dark), #1a1a1a, #ffffff);
padding: if(var(–size) = “large”, 2rem, 1rem);
}
I’ll admit, my first reaction was “do we really need logic in CSS?” But then I remembered all the times I’ve written near-identical media queries and thought better of it. The syntax takes a bit of getting used to, but it does solve a real problem.
Currently, this only works in Chromium browsers (Chrome 137+ and Edge 137+). Firefox and Safari haven’t implemented it yet, though both browser teams are discussing it. So you’ll need fallbacks for a while yet.
Native masonry layouts
Browser support: Safari Technology Preview only, behind a flag in Firefox, not in stable browsers
Grid Level 3 has finally given us proper masonry layouts – those Pinterest-style arrangements where items of varying heights fit together without gaps. Previously, this meant reaching for Masonry.js or similar. Now it’s just:
.gallery {
display: grid;
grid-template-columns: repeat(auto-fill, minmax(200px, 1fr));
grid-template-rows: masonry;
}
That last line is doing all the work. Whether “Grid Lanes” will stick as the name for this, who knows, but the functionality is solid.
The catch? It’s only available in Safari’s Technology Preview at the moment. Firefox has had it behind a flag since version 77, but it’s not enabled by default. Chrome is taking a different approach, proposing an alternative syntax outside of Grid, so this one might take a while to settle. Worth watching, but not production-ready yet.
Styling native select elements
Browser support: Chrome/Edge 135+, Safari & Firefox: Not yet supported
This one’s been a long time coming. The number of projects where we’ve had to build custom <select> dropdowns from scratch because the native ones were essentially unstylable – well, let’s just say it’s been a recurring source of frustration.
The new appearance: base-select property changes this. You can now style native selects properly using pseudo-elements like ::picker(select), all while maintaining proper accessibility and keyboard navigation. Which is possibly how it should have worked from the start.
Available in Chrome and Edge from version 135 onwards. Safari and Firefox haven’t implemented it yet. Given it’s already covering about 70% of global usage with just Chromium support, it’ll likely spread, but you’ll need fallbacks for now.
Scroll-state queries
Browser support: Chrome/Edge 133+, Safari & Firefox: Not yet supported
We’ve had Container Queries for size for a while now, but 2026 brings Scroll-State Queries. Elements can now react to being “stuck” (via position: sticky), “snapped,” or scrolled in particular directions.
The most practical example? Using @container scroll-state(stuck) to apply a shadow to a navbar only when it hits the top of the screen. No JavaScript, no scroll listeners. It just works.
Currently available in Chrome 133+ and Edge 133+, covering about 71% of global usage. Firefox and Safari don’t support it yet. It’s one of those progressive enhancement features that degrades gracefully – the navbar still works without the shadow effect.
Typography: text-box-trim
Browser support: Chrome 133+, Edge 132+, Safari 18.2+, Firefox: Not yet supported
Designers have complained about this for years – the “invisible whitespace” above and below text that makes perfect vertical alignment impossible. The text-box-trim property lets you remove that extra space:
h1 {
text-box-trim: both;
text-box-edge: cap alphabetic;
}
It’s quite satisfying when a long-standing design irritation gets a proper solution.
This one has decent support already: Chrome 133+, Edge 132+, and Safari 18.2+ all support it, covering nearly 80% of global usage. Firefox is the holdout at the moment. Given that it’s a visual refinement rather than core functionality, it works well as a progressive enhancement.
Sibling functions: Because counting is hard
Browser support: Chrome 138+, Edge 138+, Safari & Firefox: Not yet supported
The sibling-index() and sibling-count() functions let elements know their position relative to siblings. This is brilliant for staggered animations:
li {
transition-delay: calc(sibling-index() * 100ms);
}
Previously, you’d have to manually write delays for each item. This is considerably more elegant.
Available in Chrome 138+ and Edge 138+, but nowhere else yet. Covers about 59% of global usage. Given how useful this is for animation work, I expect other browsers to follow, but it’s early days.
Anchor positioning
Browser support: Chrome 125+, Edge 125+, Safari 26+, Firefox 147+
This might be the most practically useful update in quite some time. Anchor positioning lets you tether elements – tooltips, menus, popovers – to specific elements on the page, even if they’re nowhere near each other in the DOM tree.
The browser handles all the positioning maths, including automatically flipping the tooltip to the other side if it would otherwise hit the viewport edge. Which is the sort of thing that sounds simple until you’ve tried to implement it yourself.
.tooltip {
position: absolute;
position-anchor: –my-button;
bottom: anchor(top);
left: anchor(center);
position-try-options: flip-block, flip-inline;
}
This one’s actually got quite good support now. Chrome 125+, Edge 125+, Safari 26+, and Firefox 147+ all support it, covering about 76% of global usage. There’s a polyfill available for older browsers if needed. One of the better-supported new features on this list.
Cross-document view transitions
Browser support: Chrome 126+, Edge 126+, Safari 18.2+, Firefox: Partial support (144+)
Same-page transitions have been around for a bit, but 2026 brings stable Cross-document View Transitions. This means standard multi-page apps can now have the smooth “morphing” effects previously reserved for complex single page apps.
When you click a link, the browser captures the current state and animates it into the next page. Whether this is always appropriate is debatable, but when it works well, it works very well indeed.
Available in Chrome 126+, Edge 126+, and Safari 18.2+. Firefox has partial support from version 144+ (behind a flag). Covers about 80% of global usage. Given it’s an enhancement to navigation rather than a requirement, it degrades well for unsupported browsers.
Scroll-driven animations
Browser support: Chrome 115+, Edge 115+, Safari 26+, Firefox: Behind flag only
CSS can now link animation progress directly to scroll position or viewport visibility. This replaces libraries like ScrollMagic. There are two main approaches:
- animation-timeline: scroll() – animation progresses as you scroll
- animation-timeline: view() – animation triggers as elements enter or exit the viewport
The performance is considerably better than JavaScript alternatives, which is no small thing.
Chrome 115+, Edge 115+, and Safari 26+ all support this, covering about 78% of global usage. Firefox has had it behind a flag since version 110, but it’s not enabled by default in stable releases. Given the performance benefits, it’s worth using with appropriate fallbacks.
Native carousel components
Browser support: Chrome 135+, Edge 135+, Safari & Firefox: Not yet supported
Chrome has introduced pseudo-elements specifically for building carousels without JavaScript:
- ::scroll-button(up/down/left/right) automatically generates functional navigation buttons
- ::scroll-marker generates pagination indicators
Whether we should be encouraging more use of carousels is a separate question (and one I’m not sure I have a definitive answer to), but if you’re going to build one, native support makes the process considerably cleaner.
Available only in Chrome 135+ and Edge 135+ at the moment, covering about 69% of global usage. Safari and Firefox haven’t implemented these yet. Given how new this is, you’ll definitely want JavaScript fallbacks for now.
What this means, probably
The pattern is clear enough: JavaScript is moving to the background. It’s still essential for complex application logic and data handling, but a lot of the “UI glue” is shifting back to CSS and the browser’s native capabilities.
This should result in faster page loads, smoother animations, and less code to maintain. Whether it will actually work out that way depends on how sensibly we use these new tools. The history of web development suggests we’ll find creative ways to overcomplicate things regardless of the tools available.
But I’m cautiously optimistic. These features solve real problems without requiring us to completely rethink our approach to building websites. And that, honestly, is about as much as you can ask for.
The staggered browser support does mean we’re in for a transitional period where progressive enhancement and feature detection become more important than ever. But that’s not necessarily a bad thing – it forces us to think about fallbacks and ensures sites remain functional for everyone.