Shared Element Transitions - Early Review

[ianvollick]

Ya ya yawm TAG!

I'm requesting a TAG review of the Shared/Root Element Transitions API.

Summary

Shared Element Transitions is a proposal for a new script API that allows a simple set of transitions in both Single-Page Applications (SPAs) and Multi-Page Applications (MPAs).

The inspiration for this feature are transitions similar to the ones listed in the Material Design Principles.

The intent is to support transitions similar to Android Activity Transitions.

In the SPA case, this entails capturing pre-transition visuals, updating the page, and animating to the post-transition state. The API for MPAs is still being designed (issue here).

• Explainer (minimally containing user needs and example code): https://github.com/WICG/shared-element-transitions/blob/main/README.md
• Security and Privacy self-review: https://github.com/WICG/shared-element-transitions/blob/main/security-privacy-questionnaire.md
• GitHub repo (if you prefer feedback filed there): https://github.com/WICG/shared-element-transitions
• Primary contacts (and their relationship to the specification):
  • Vladimir Levin (@vmpstr), Google (editor)
  • Ian Vollick (@ianvollick), Google
  • Chris Harrelson (@chrishtr), Google
• Organization/project driving the design: Google
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://chromestatus.com/features#shared%20element%20transitions

Further details:

• ✅ I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
• The group where standardization of this work is intended to be done ("unknown" if not known): CSSWG
• Existing major pieces of multi-stakeholder review or discussion of this design: n/a
• Major unresolved issues with or opposition to this design: desire for more control over customization (eg, 1, 2)
• This work is being funded by: Google

We'd prefer the TAG provide feedback as (please delete all but the desired option):

☂️ open a single issue in our GitHub repo for the entire review

[torgo]

Hi @ianvollick. Thanks for raising this to us. We're just discussing in today's call and one question that I had is: can you clarify the issue you've raised in the security & privacy answers regarding sites opting in to this behaviour (possibly with a specific example)?

[LeaVerou]

Hi there @ianvollick!
We looked at this today during a breakout and we had several questions for you:

• The explainer currently lacks a list of use cases, so it's difficult to assess whether this covers the user needs and developer needs it was designed to address, or even what these are.
• It was unclear to us whether this API adds new functionality that is not possible using existing Web Platform features (such as CSS transitions and animations, or Web Animations), or whether it's a higher level abstraction of commonly needed functionality that is already possible, just harder.
• It was unclear to us what the reasoning is for an entirely new API over a more layered approach over the existing Web Platform features mentioned above.

Could you please clarify?

[ianvollick]

Thank you for taking a look! Responses inline.

Hi @ianvollick. Thanks for raising this to us. We're just discussing in today's call and one question that I had is: can you clarify the issue you've raised in the security & privacy answers regarding sites opting in to this behaviour (possibly with a specific example)?

In this case, I'd flagged this since I thought this would be of interest to the landing site rather than the user. In that sense, this may not be a Security & Privacy issue (though this could be impacted by the eventual design of the multi-page API [1]).

I can certainly give some more detail, though. Say we have a page that wants to link to another site (perhaps a recipe) and would like to animate a hero image into place on the second page. On page A, the image might be a picture of a pie, and on page B, this might be a picture of the ingredients on the table and the transition would slide the image into place.

Now, say site B would prefer not to have such a transition to their page. We had suggested in the questionnaire that site B could state a preference that this not happen, but an opt-in is also something that we're considering and may be the right approach in some cases.

[1] For example, if we go with a declarative API, we don't expect this to be observable by script, and if the Security & Privacy Questionnaire responses change as multi-page API is developed, we will request a re-review.

Hi there @ianvollick!
We looked at this today during a breakout and we had several questions for you:

• The explainer currently lacks a list of use cases, so it's difficult to assess whether this covers the user needs and developer needs it was designed to address, or even what these are.
• It was unclear to us whether this API adds new functionality that is not possible using existing Web Platform features (such as CSS transitions and animations, or Web Animations), or whether it's a higher level abstraction of commonly needed functionality that is already possible, just harder.
• It was unclear to us what the reasoning is for an entirely new API over a more layered approach over the existing Web Platform features mentioned above.

Could you please clarify?

Here's a list of a few possible use cases

• When navigating from a list-page to a details-page, the site author may want a) the picture of the item, and b) the name of the item to persist through the transition and animate into position when changing states. An animated example is shown here.
• cover- / reveal-
  • Can be used to create a "slide to next/prev card in a series" effect. An animated example of that is given here (please see the "Relationships" section).
• explode / implode
  • Can be used to, semantically, show that the user is adding/removing a new state on a stack (eg showing/hiding settings menu). This is also illustrated by the example above.
• Providing visual context or seamless flourish for the user when navigating between different sites or pages within a site. For example, say on page A, we have a small card containing a link and the author would like the card to stick around and hover for a moment while the next page B loads and renders, then animates into place.

It isn't possible to achieve these effects in a multi-page application (MPA) since elements cannot persist across a transition between pages. Some folks end up creating SPAs just to create these kinds of effects, and wouldn't have to once we have an MPA-friendly API. In the SPA case, it is certainly possible to create many of these effects today, though it is cumbersome. In our research, it has proven so cumbersome that sites often simply don’t do it (two very large, well-funded, non-Google web properties told us as much). The complication with SPAs is that we need to have live DOM available for both states at the same time, and it's common to get the details wrong (eg, old state might remain clickable, the outgoing state may stick around after the transition), leading to difficult-to-debug issues and can have a negative impact on accessibility. We feel that an API such as this would make authoring this sort of transition extremely easy, and offer better performance and user agent control (e.g. to skip animations when the user doesn't want it).

The question of whether we could layer atop existing APIs is a good one and related to some developer feedback we've already received [2]. We certainly aim to permit customization of these effects (we're currently preparing for an origin trial to learn more about what customizations are most needed), but the initial API shape was chosen to provide a convenient way to "snapshot" page state at a given point of time and provide UA-defaults for common transitions.

That said, I think this API could definitely be made more idiomatic and reuse concepts (eg, using easing functions to specify curves, or something like the suggestion in [2]). I expect that this will evolve a lot in the specification process – this is a very early review; the multi-page API hasn't even been sketched (and for this, one approach we're considering is entirely CSS-based).

[2] WICG/view-transitions#28

[hober]

The inspiration for this feature are transitions similar to the ones listed in the Material Design Principles.

The intent is to support transitions similar to Android Activity Transitions.

I can think of two other sources you should look at.

• One, you're looking at Android but not iOS. I assume both operating systems have existing behavior you could support.
• Two, PowerPoint and Keynote both have inter-slide transitions that allow specific elements on each slide to morph into a corresponding element on the next/prev slide. These program's default set of inter-slide transitions should probably be pretty high priority.

[cynthia]

One, you're looking at Android but not iOS. I assume both operating systems have existing behavior you could support.

and Windows, for completeness.

[khushalsagar]

Thanks hober and cynthia! Those are definitely good areas to look at for inspiration in researching this space more.

[LeaVerou]

Hi @ianvollick!

We looked at this again during a breakout in our Gethen (V)F2F today.

In terms of the proposal that is outlined in this explainer, we feel that an API for Shared Element Transitions (SETs) should provide the kinds of primitives that designers can use to define transitions, not only expose a small predefined set of “canned” effects, which tends to not scale well over time as design trends and collective aesthetics evolve.

But more importantly, while SETs in SPAs are useful, we still feel that MPAs are by far the primary use case and the SET API needs to be designed with both in mind. We don’t want to end up with two separate SET APIs, one for SPAs and one for MPAs. The current proposal only works for SPAs with no obvious way to extend it to MPAs. SETs for MPAs appear to be in the early brainstorming phase, so there is not much for us to comment on, besides that we certainly recognize that there is a strong user need.

Therefore we are going to close this and look forward to reviewing it again in the future when there is a concrete API proposal to review.

[ianvollick]

Hi TAG,

We’ve taken your feedback and updated our proposal. The new explainer describes an API that is built on existing animation primitives. Specifically, the API creates new pseudo-elements that are targetable by CSS and a set of default CSS animations. Developers can target these pseudo elements using existing CSS concepts and animation APIs (CSS transitions, animations and Web Animations) to customize their transitions.

This explainer also delves deeper into how this API will work in a same-origin different-document navigation. We believe that the updated API can serve both the SPA and MPA use-cases.

We would appreciate it if you could take another look at this proposal. We look forward to your comments and thanks in advance!

(Would you be able to reopen this issue while the discussion continues?)

[vmpstr]

Note that a draft of the spec for SPA portion available here https://tabatkins.github.io/specs/css-shared-element-transitions/. This doesn't include MPA transitions, but those should be described in some detail in the explainer.

[khushalsagar]

The review for the updated API is being discussed here.