Re: [w3ctag/design-reviews] Shared Element Transitions - Early Review (#631)

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](https://github.com/WICG/shared-element-transitions/blob/main/security-privacy-questionnaire.md#01-what-information-might-this-feature-expose-to-web-sites-or-other-parties-and-for-what-purposes-is-that-exposure-necessary) 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](https://developer.android.com/training/transitions/start-activity).
* cover-<direction> / reveal-<opposite direction>
  * Can be used to create a "slide to next/prev card in a series" effect. An animated example of that is given [here](https://material.io/design/motion/the-motion-system.html#transition-patterns) (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] https://github.com/WICG/shared-element-transitions/issues/28



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/631#issuecomment-856265760