@view-transition {
navigation: auto;
}That is the entire opt-in for cross-document view transitions. The page you leave and the page you load both need it, and once they have it the browser cross-fades from one document into the next instead of cutting hard. The June 2 performance chat summary on Make WordPress Core leads with ticket #64471, which proposes exactly this for the WordPress frontend, so I spent an evening with the tickets and the browser docs to work out what it means for the sites I build.
My read: core wants the frontend to feel less like a document swap, without a router or any JavaScript, and without a theme rewrite. That’s a reasonable goal. The argument worth having now, while it’s still a ticket and not a merge, is whether it should be on by default for every site or opt-in, because defaults in core tend to be forever. I touched on this team’s output before in my notes on the WordPress 7.0 performance chat, and the pattern holds: the interesting decisions happen in these small weekly chats.
What core is proposing
Ticket #64471 aims to add cross-document view transitions on the frontend. Mechanically, the browser takes a snapshot of the old document, loads the new one with rendering suppressed, then animates between the two using ordinary CSS animations. There is no document.startViewTransition() call anywhere, because the navigation itself is the trigger. MDN’s reference covers the at-rule and its constraints, and Chrome’s write-up explains how the pieces fit together.
The constraints matter for WordPress. Both documents must be same-origin, without a cross-origin redirect, and the navigation has to be a user-initiated traverse, push or replace. A plain link click qualifies, and so does the back button. A form POST does not, and neither does a script setting window.location.href. That’s a sensible set of limits, and it saves core a lot of edge cases.
The admin is already the test bed. The chat flagged an open bug with view transitions in the admin, tracked in #65032; PR #11912 is ready for review and fixes the admin menu view transition animation. It also highlighted #65294, which reports a temporary blank white screen when creating a new post. That one sounds minor until an editor reports it, because “the screen went white” is the kind of ticket that never reproduces while you’re watching.
There was housekeeping too: performance repo issue #2437 is cleaning up deprecation warnings in the wp-env test environment. It won’t change your week, but keeping that CI clean matters more than it sounds, same as the auto-sizes roadmap work the team has been grinding through.
Can you add cross-document view transitions to a theme today?
Yes, and it’s boring in a good way. Put the at-rule in the stylesheet every page shares, so the front page, archives and singles all opt in. Wrap it in @media (prefers-reduced-motion: no-preference) so people who ask their system for less motion get a normal navigation instead. The at-rule can be nested inside a media query, and browsers without support ignore it, so there is nothing to feature-detect and nothing to break.
On support: Chrome has had this since 126, Safari picked it up in 18.2, and Firefox is the one I wouldn’t plan around yet. That gap is exactly why a theme-level opt-in beats waiting. I don’t know whether core will ship #64471 enabled for everyone or behind a flag, and that choice decides whether themes should keep their own rule or defer to core. Watch the ticket rather than guessing.
One WordPress-specific reassurance: page caching doesn’t interfere. The rule lives in your global stylesheet, so a cached page and a freshly rendered page both carry it, and the transition fires either way. You don’t need a cache exclusion or a nonce.
What happens on a WooCommerce store?
Mostly nothing, and that’s the good news. Add-to-cart and checkout are POST navigations, and POSTs don’t trigger a transition, so the money flow behaves exactly as it does today. Same-origin also means a checkout pinned to a separate subdomain won’t animate, which nobody will miss.
Where it pays off is the grid-to-product morph. Give the product image on the archive a view-transition-name, give the main gallery image on the single product page the same name, and the browser animates one into the other. The hard rule is that names must be unique per page: if two elements share a name, the browser skips the transition, so a product loop needs generated names such as product-image-{ID}.
A transition can’t hide a slow destination document. If the single product page takes two seconds to arrive, the customer waits two seconds, cross-fade or not. It improves perceived smoothness, which does count for something on a store, but it earns you nothing on a Core Web Vitals report.
This week I’d add the rule on staging for a content site, click around in Chrome and Safari, and pay particular attention to back and forward navigation. Check the reduced-motion path once. Leave production stores alone until #64471 lands and the admin bugs behind it, #65032 and #65294, are settled. If you want a second pair of eyes on whether your theme or your store can take this safely, that’s work I do regularly and I’m glad to look at it.
