Add view transitions theme support in abstracted way with sensible defaults

[felixarntz]

This PR explores adding cross-document view transitions to WordPress Core. These enable smooth transitions between URL navigations and thus can improve user experience.

Learn more about cross-document view transitions

For browser support, see https://caniuse.com/mdn-css_at-rules_view-transition

High-level approach

• In principle, how view transitions should be applied heavily depends on the layout and markup of each site. WordPress themes are rather unpredictable in that regard - for the most part.
• This PR focuses on identifying aspects where themes have things in common. Specifically, a smooth transition between certain elements of a post (e.g. navigating between the singular post URL and the same post within a blog or archive URL) seems achievable.
  • For classic themes, the post is almost always wrapped in an article.post element or, sometimes on the singular post URL it's not wrapped specifically, but this we can detect via body.single selector.
  • For block themes, it's equally straightforward, as there a post is almost always wrapped in a .wp-block-post.post element.
  • We can identify between which post the navigation happens by comparing the URL that is being navigated to or from with the specific .post element on the page that contains an a link pointing to that same URL. That way we can achieve a nice effect where relevant post elements (in this PR so far the post title and featured image) shift to their location within the other URL.
• For block themes, this is overall by far the most straightforward, since their markup is far more predictable, so it should be reasonable to enable view transitions for block themes by default.

What's supported?

API

• This PR opts in every block theme and very classic default theme to using cross-document view transitions.
• Any theme can opt in by calling add_theme_support( 'view-transitions' ).
• Optionally, themes that opt in can provide configuration arguments to fine-tune the default behavior by providing an array of arguments in the call: See https://github.com/WordPress/wordpress-develop/pull/8370/files#diff-b9f1810ad43acfa11ba58a9f21eb0ee3a8063c80aa155de9b210323252534716R2938 for the supported arguments.
• For now, none of the opted in themes provides custom arguments. This is so that we can first focus on testing and validating the most suitable default behavior before getting into fine-tuning.

Transition behavior

• Overall, the entire content on any URL will fade over to the next one. This is the very basic foundation of view transitions and, while maybe quite nice, not very useful on its own. It's the more specific transitions that make it visually appealing (see below).
• When navigating between an archive view URL and a single post URL within that archive, the following elements will morph between the two URLs (e.g. transitioning between their locations and transforming in size accordingly):
  • the overall page header
  • the overall page content
  • the specific post title being navigated to/from
  • the specific post thumbnail / featured image (if present) being navigated to/from
  • the specific post content (if present) being navigated to/from
• If pretty permalinks are enabled:
  • When navigating between different pages of the same archive view, the overall page content will slide to the left if moving to a higher page, or to the right if moving to a lower page, while the rest of the page remains in place.
  • When navigating between different pages of a multi-page post (rarely used, can be achieved via "Page Break" block), the specific post content will slide to the left if moving to a higher page, or to the right if moving to a lower page, while the rest of the page remains in place.
  • When navigating from a post to the previous or next post, the overall page content will slide to the left if moving to a newer post, or to the right if moving to an older post, while the rest of the page remains in place. This only works if the permalinks are configured to include the date (e.g. /%year%/%monthnum%/%day%/%postname%/).

Testing

1. Use a compatible browser (see https://caniuse.com/mdn-css_at-rules_view-transition).
2. Simply apply the PR to your codebase, or use WordPress Playground.
3. Create a few posts with non-empty titles and any content, most of them with a featured image. 3-4 posts should be enough for testing.
4. Try using any of the WordPress default themes, navigating between blog/archive views and specific posts on them to see the view transitions in effect.

Next steps

I tested all default themes with how they behave, and it works for almost all of them:

• 2025: Works out of the box.
• 2024: Works out of the box.
• 2023: Works out of the box.
• 2022: Works out of the box.
• 2021: Works out of the box.
• 2020: Works out of the box.
• 2019: Requires custom configuration due to special handling of full-screen featured images.
• 2017: Requires custom configuration due to special handling of full-screen featured images.
• 2016: Works out of the box.
• 2015: Works out of the box.
• 2014: Works out of the box.
• 2013: Works out of the box.
• 2012: Works out of the box.
• 2011: Works as well as it can, because featured images aren't even displayed in blog or archive views.

Obviously, more at-scale in research and testing is needed, to see how other themes (especially classic themes) handle those areas in terms of markup and whether they would also work out of the box or would require customizations. But this is a start :)

Trac ticket:

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[github-actions]

Test using WordPress Playground

The 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

• The Plugin and Theme Directories cannot be accessed within Playground.
• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.