I still have nightmares about jQuery .animate().
If you were building websites fifteen years ago, you remember the jank. You remember the callbacks nested six levels deep just to slide a dropdown menu open without it looking like a PowerPoint presentation from 1998. We’ve come a long way. But looking at the state of CSS transitions right now—specifically the intersection of View Transitions and Anchor Positioning—I’m feeling a mix of relief and mild vertigo.
Actually, let me back up—it’s February 2026. The dust has mostly settled on the “new” transition specs that everyone was screaming about last year. I’ve been pushing this stuff into production on a client project for the last three weeks, and I have some thoughts. Not the polished “look how shiny this is” thoughts. The “I broke the layout three times and here’s why” thoughts.
Multi-Page View Transitions Are (Finally) Boring
And I mean “boring” as the highest possible compliment.
Remember when the View Transitions API first dropped? It was this magical, fragile thing that only worked in Chrome and required a blood sacrifice to get working across full page reloads. But, generally, it just works now. mostly.
I updated our main marketing site last Tuesday to use cross-document view transitions. The goal was simple: keep the persistent header stable while the content area fades and slides. No React Router, no SPA framework hijacking the history API. just raw HTML and CSS.
The code looked something like this:
@view-transition {
navigation: auto;
}
header {
view-transition-name: main-header;
}
That’s it. Two years ago, this would have required a Service Worker and a prayer. But, typically, running Chrome 143 (I’m on the dev channel, don’t judge), it detected the navigation, froze the old state, and morphed the header perfectly into the new page’s header position. No flash of white. No layout shift.
The Gotcha: Safari 19.1 still has this weird quirk where if you have a border-radius on the transitioning element, it occasionally clips the content during the snapshotted animation frame. I spent two hours thinking I messed up the z-index. I didn’t. It’s a rendering bug. If you’re seeing jagged corners during a transition on iOS, force hardware acceleration on the snapshot pseudo-element. You’re welcome.
Anchor Positioning is the Real MVP
And, But while everyone was obsessing over full-page swooshes, Anchor Positioning quietly solved the most annoying problem in UI development: Tooltips.
Or popovers. Or select menus. Basically, anything that needs to sit next to something else but not inside it.
I ripped out about 400 lines of JavaScript last week. It was a messy usePopper implementation that calculated coordinates on every scroll event. It was heavy, it caused layout thrashing, and I hated it. Replacing it with CSS anchors felt illegal.
The thing is, though, nobody tells you: animating tethered elements is tricky.
When you tether an element using position-anchor, the browser handles the layout. But if you want to transition that element’s position when the anchor moves? The browser tries to be smart and snap it. If you want a smooth glide, you have to explicitly tell the browser to transition the top and left properties, which… wait for it… aren’t actually set by you.
I ran into this wall hard. My tooltip was jumping around like a nervous squirrel.
The Fix
You have to use the position-try-fallbacks with a transition on the transform property, not the positioning properties. It’s counter-intuitive. The browser calculates the new spot, and you use a transition to slide into it.
Tested this on a low-end Android device (some random Galaxy A-series from 2023 we keep in the drawer). The JS version used to drop frames like crazy. The CSS version? Locked at 60fps. The CPU usage on the main thread dropped by roughly 12% during scroll interactions. That is not a typo.
The Customizable Select Mess
Okay, let’s talk about the <select> element. Or <selectlist>. Or whatever the spec authors are calling it this week (it’s settled on appearance: base-select now, thankfully).
We can finally style the dropdown. We can put images in options. We can make it look like it belongs in 2026 and not 1995. But animating the opening state? That is still a minefield.
I tried to add a simple expand animation:
select::picker(opening) {
animation: slide-down 0.2s ease-out;
}
It works. But if you have overflow: hidden on a parent container (which, let’s be honest, you do), the picker often gets clipped during the animation *before* it gets promoted to the top layer. It pops out, gets cut off, and then snaps to full visibility.
I had to hack around this by using the new ::picker-icon pseudo-element to drive the transition state. It’s messy. It feels like the old days of clearing floats.
Why I’m Still Optimistic
Despite the Safari clipping bugs and the weirdness with select animations, this is the probably the best it’s ever been.
I remember writing a “comprehensive guide” to transitions in 2018 that was basically just “don’t animate height, it hurts performance.” Now I’m animating height, width, position, and cross-document states, and the browser engine handles the heavy lifting.
One specific thing I noticed yesterday: The view-transition-class property. I have a grid of 50 product cards. Previously, I had to give each one a unique view-transition-name in a loop. It cluttered the DOM and felt dirty. With view-transition-class, I just tagged them all as .product-card and the browser figured out the geometry matching automatically.
It failed on the first try, obviously. I had two cards with the same ID in the database (don’t ask). The console error was actually helpful: “Duplicate view-transition-name found.” It pointed right to the element. In 2022, that would have just silently failed, and I would have lost my mind.
A Warning on Performance
Just because you can transition everything doesn’t mean you should.
And I got carried away. I admitted it. I added view transitions to every tab switch, every list filter, every page load. The site felt “heavy.” Not slow, just… thick. Like wading through molasses. Users don’t want to wait 300ms for a menu to fade in. They want the menu.
I dialed it back. Now, we only use the full View Transition API for major context switches (like going from a list to a detail view). For small interactions, standard CSS transitions are probably faster and feel snappier.
Also, watch your memory usage. Snapshotting the entire DOM tree for a transition isn’t free. On my M3 MacBook, it’s fine. On that old Android phone I mentioned? A complex page transition spiked memory usage by about 40MB for a split second. If you’re running a heavy app, that spike can cause a crash.
So yeah. Use the new toys. They’re great. But maybe don’t use all of them at once.
