Refine the admin menu view transition animation#11912
Conversation
Clip each top-level menu item's view transition snapshot to its animating group box. By default a captured snapshot keeps its full intrinsic height, so a newly expanded submenu painted at full height from the first frame and overlapped the menu items below while they were still sliding into place. Setting `overflow: clip` on the image pair makes the submenu wipe open, and closed in reverse, in step with those items. Also name the collapse button so it slides into place with the menu items rather than cross-fading via the page root, and add comments explaining each rule. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Test using WordPress PlaygroundThe changes in this pull request can previewed and tested using a WordPress Playground instance. WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser. Some things to be aware of
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
|
In the following videos, I have a plugin active which slows down the animations to make them more observable: add_action(
'admin_print_styles',
function () {
?>
<style>
/* TEMP DEBUG: slow every view transition animation down to 2s. Remove before shipping. */
::view-transition-group(*),
::view-transition-old(*),
::view-transition-new(*) {
animation-duration: 1s;
}
</style>
<?php
}
);Before:Screen.Recording.2026-05-20.at.16.26.37.movAfter:Screen.Recording.2026-05-20.at.16.28.04.mov |
A cross-document view transition snapshots the incoming page at its first render, which can occur before the body has finished parsing. When that happens the admin menu is only partially built in the snapshot, so the menu-top elements have no height delta and the section accordion silently degrades to a plain cross-fade. Print a render-blocking `<link rel="expect">` pointed at the end of the body, so the first render — and therefore the transition's snapshot — waits until the page is fully parsed. The media query scopes the small first-render delay to when view transitions run. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Diagnosing the intermittent accordion failureSymptom. Navigating between admin sections, the menu "accordion" (one section's submenu collapsing as the next expands) usually played, but intermittently degraded to a plain cross-fade with no movement. It was hard to reproduce — and, crucially, it happened more often with DevTools closed. Ruled out along the way:
Instrumentation. A temporary Root cause. Every captured failure showed the same two things: A cross-document view transition snapshots the incoming page at its first render, and the browser paints incrementally — so first paint (and therefore the snapshot) can happen before the Fix. A render-blocking expectation in the admin <link rel="expect" href="#wpfooter" blocking="render" media="(prefers-reduced-motion: no-preference)">This holds the first render — and so the view transition's snapshot — until The two CSS refinements in the first commit — clipping each menu item's snapshot so a submenu wipes open/closed instead of overlapping the items below, and naming |
…hould return string but returns string|false.
1 participant
Trac ticket: https://core.trac.wordpress.org/ticket/65032
When view transitions were enabled throughout wp-admin in 7.0, each top-level admin menu item was given a stable
view-transition-name, so navigating between sections animates them into place (the "accordion" effect). Three rough edges remained:<body>has finished parsing. The snapshot then captures a half-built admin menu, so the menu items have no height delta and the accordion silently degrades to a plain cross-fade. It reproduces most easily with DevTools closed;pagerevealinstrumentation confirmed the snapshot being taken atreadyState: "loading"with an incomplete menu.#collapse-menu) was not named, so it cross-faded as part of the page root instead of moving with the rest of the menu.Changes
<link rel="expect" href="#wpfooter" blocking="render" media="(prefers-reduced-motion: no-preference)">in the admin<head>, so the first render — and therefore the transition's snapshot — waits until the page is fully parsed. The snapshot then always captures a complete menu and the accordion runs reliably. Themediaquery scopes the small first-render delay to when view transitions actually run.view-transition-class(wp-menu-top) to every top-level menu item and setoverflow: clipon::view-transition-image-pair(.wp-menu-top). This clips each menu-top's snapshot to its animating group box, so an expanding submenu wipes open from the link row to full height — and wipes closed in reverse — in step with the items below it, instead of overlapping them.#collapse-menuits ownview-transition-nameso it slides into place with the menu items rather than cross-fading via the root.Files changed:
src/wp-admin/css/view-transitions.css,src/wp-includes/view-transitions.php,src/wp-includes/default-filters.php.Testing instructions