Plugin Proposal: View Transitions

[felixarntz]

Overview

• Proposed plugin name: View Transitions
• Proposed plugin slug: view-transitions
• Proposed plugin owner GitHub username(s): @felixarntz

About the plugin

Purpose

The proposed feature plugin will provide a WordPress-specific API to enable cross-document view transitions via theme support. For the WordPress sites that use the plugin, it will opt these sites in to using that API. The emphasis lies on the "API" because, if this API was merged into WordPress Core, it might be an opt-in theme support feature, just like most other theme support features work.

The use of this plugin will eventually inform the decision-making process, e.g. whether the API's default behavior is suitable for >80% of WordPress sites (and specifically their themes) or not.

The View Transitions API, which the plugin will use under the hood, is a web API that allows creating seamless visual transitions between different URLs on a website. This creates a more visually engaging user experience and enhances perceived performance. It also allows traditional websites to finally compete with native apps in that regard - without the View Transitions API, the only way to achieve smooth transitions on the web was to use an SPA architecture, something that's extremely uncommon and not truly supported in WordPress.

While the View Transitions API can be used for same-document transitions (SPA) and cross-document transitions (MPA), due to the cross-document setup of almost all WordPress sites, the plugin only focuses on the latter.

The View Transitions web API is currently supported by Chromium and Webkit browsers, with Mozilla having indicated support (see caniuse). There is also the W3C specification for cross-document view transitions specifically.

Learn more about the View Transitions API.

Scope

Much of what the plugin would do was initially implemented as an experimental WordPress Core PR:

• new theme support feature view-transitions that allows opting in to cross-document view transitions in the site's frontend, with optional configuration arguments supported
  • when opted in, the plugin would enqueue a script and a stylesheet that enables the behavior
  • the stylesheet will opt in via @view-transition and define certain transition animations
  • the script will dynamically determine how to transition exactly, based on the URLs and content navigated between
• defaults that rely on WordPress Core provided markup (either block classes added by Core, or classes from functions like post_class() or the_post_thumbnail()) to enable config-less appealing view transitions
  • the primary focus would be on transitioning post titles and post featured images between their singular URLs and their placement within archive URLs
  • certain generally static areas like e.g. the URL's header would transition individually as well
  • other transitions could be considered (either to test as a default, or opt-in only), such as slide-in/slide-out when transitioning between two URLs that fall under the same pagination hierarchy (e.g. going from /blog/page/2/ to blog/page/3)
• the plugin would automatically opt in the site to use the view-transitions theme support feature
  • for the WordPress default themes, where applicable, it may alter their configuration automatically
  • that being said, the ideal outcome is to get appealing view transitions for all of the default themes out of the box (just like for any other theme)
• potentially some of the configuration arguments could be controlled via a settings UI in the plugin
  • this would not be taken into account for a potential WordPress Core merge, but it would help with plugin exploration
• it could also be explored to include certain appealing visual animations to select from

Out of scope (at least for the foreseeable future) are view transitions in WP Admin. With much fewer users navigating through the WP Admins of the world, plus an anticipated WP Admin rewrite in the future, it does not make much sense to focus on this at the moment. It could be explored in the long-term future.

Rationale

See above:

This creates a more visually engaging user experience and enhances perceived performance. It also allows traditional websites to finally compete with native apps in that regard - without the View Transitions API, the only way to achieve smooth transitions on the web was to use an SPA architecture, something that's extremely uncommon and not truly supported in WordPress.

While using view transitions does not improve the actual performance of a site, the aspect of perceived performance is quite relevant for user experience too. Additionally, the ability to have smooth transitions between different URLs is kind of revolutionary on its own :)

Enabling view transitions in WordPress Core is a distinct feature that lends itself perfectly to becoming a feature plugin.

Other

Fun fact: A single usage of the View Transitions API is already in WordPress Core (via Gutenberg), for the Site Editor toggle in WP Admin: https://github.com/search?q=repo%3AWordPress%2Fgutenberg%20view-transition-name&type=code

[westonruter]

While using view transitions does not improve the actual performance of a site, the aspect of perceived performance is quite relevant for user experience too.

I'd argue that it fits in Performance Lab given the close affinity between View Transitions and Speculative Loading (which is part of PL), although strictly VT is not a performance improvement. Nevertheless, I'd argue it's somewhat of a fix for a sometimes-unsettling immediacy of page navigations that prerendering enables.

So it's somewhat of a UX performance improvement in the same way as Image Placeholders improves the "performance" of the user experience.

[joemcgill]

Excited to see some thought going into this! I'm curious why (besides familiarity) it would be better to make this a standalone performance plugin, rather than iterating on this feature directly in the Gutenberg repo, similar to the way the Interactivity API is developed?

[westonruter]

Something like the Interactivity API needs to have hooks deep into the Gutenberg codebase to be developed. View Transitions, however, can be developed as a layer on top of existing themes, so there isn't the same coupling needed. That said, it could be developed as part of Gutenberg. However, if it were specifically part of Gutenberg, then I'd think the scope would necessarily be for block themes whereas the the view transitions proposed here include theme support for classic bundled themes.

[felixarntz]

@joemcgill

I'm curious why (besides familiarity) it would be better to make this a standalone performance plugin, rather than iterating on this feature directly in the Gutenberg repo, similar to the way the Interactivity API is developed?

To me, the main reasons are:

• The feature is performance related and therefore aligns with other plugins we have.
• The feature is decoupled from what Gutenberg otherwise does, so there is no technical benefit of including it in Gutenberg.

I'd say neither of these two are necessarily strong reasons not to include it in Gutenberg, but on the flip side I can't think of good reasons to include it in Gutenberg either.

I think the trickiest thing about including this in Gutenberg would be that it's its own feature so the question would be how do we roll this out to people with intent, but also at a scale that's worthwhile. For example:

• This is probably too experimental to enable for all sites using Gutenberg.
• If it was an experimental feature in Gutenberg, it's too hidden in some advanced UI.
• Site owners may want to test view transitions specifically, without using the bleeding-edge enhancements from the Gutenberg plugin, which have increased risk of including breaking changes.

[joemcgill]

Thanks, @felixarntz. Those are all valid points. I think starting out as a standalone plugin makes sense. At some point it might be interesting to try to integrate this into GB as an experiment that also allows some transitions to be controlled from the site editor, but it's much too early to know if that would even be useful/needed now.

[swissspidy]

Regarding configuration, I would love to see some exploration leveraging Optimization Detective to automate some of the process. Of course a stretch goal, but wanted to mention it.

[felixarntz]

@swissspidy Curious to get more context on your idea. What do you see as OD's potential role in this?

Since view transitions don't have as clear best practices as performance, I'm not sure how OD would be able to automatically make decisions about how view transitions should behave - it's often a design decision. That's why I'm not sure I understand what you mean.

[swissspidy]

I was specifically referring to automatically annotating things like post titles and featured images with the right view transition names.

[felixarntz]

Hmm, what benefits would that have over Core doing it? IMO the power of Optimization Detective comes primarily from its cilent-side detection. But for knowing whether something is a post title or featured image, I think WordPress Core itself (on the server-side) is best set up.

[swissspidy]

Yeha maybe it doesn't need OD, but just some basic filters to add the necessary annotations. Implementation details :-) What I want to advocate for is finding a way to automate things instead of requiring custom configs like 'post-selector' => '.wp-block-post.post, article.post, body.single main',

[felixarntz]

You mean have OD identify which selectors the site uses for e.g. post titles and post featured images? That is worth trying.

What I want to advocate for is finding a way to automate things instead of requiring custom configs like 'post-selector' => '.wp-block-post.post, article.post, body.single main',

The plugin wouldn't require a custom config, the example value you mention there would be a default, and probably works for the vast majority of themes. But maybe OD could be used optionally on top of that to increase accuracy, like it does with most other things it implements. Like e.g. let's say this default works for 75% of themes, maybe OD could bring it to 95% or so.