Contact emailskhusha...@chromium.org, vmp...@chromium.org, hvano...@chromium.org
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).
This feature enhances the visual polish of pages without requiring a large development effort from developers to make transitions look nice. By selecting from a set of user-agent implemented transition effects, the developers can achieve a polished transition look with minimal effort.
TAG review statusPending
Link to origin trial feedback summaryhttps://docs.google.com/spreadsheets/d/1x7IueF5_Ds7oyihAV1DB3yzR4f-SbPcKc5DMvBzg-nM/edit#gid=2085648173
Interoperability and Compatibility
Low. As a new feature, the risk here is that other browsers do not implement it, but since this is a progressive enhancement, sites should be able to drop usage of the feature easily in browsers where it is not supported.Gecko
: No signalWebKit
: No signalWeb developers
: Strongly positive
Interest and developer experiments with the API:
As with interop/compat risks, the difficulty stems from this being a new feature without support in other browsers. A polyfill for the SPA case would be beneficial, but it will not be possible to polyfill MPA behavior. That said, dropping the customized transition should not impact the usability of a site, fundamentally, so this can easily be dropped on browsers that do not support the feature.
The primary security constraint is ensuring isolation of graphics resources from multiple origins. The design achieves that using Chromium's Viz process similar to OOPIFs.
See also the security and privacy self-review questionnaire that was completed as part of the TAG review process: https://github.com/WICG/shared-element-transitions/blob/main/security-privacy-questionnaire.md
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
Goals for experimentation
Learning from the feedback from the previous OT, the API has been updated to layer on top existing animation systems on the platform. This allows the browser to provide a set of default transitions which developers can extensively customize.
We want to learn that developers can easily adopt this API and build the desired UX using the customization options provided.
Reason this experiment is being extended
Ongoing technical constraints
The feature can be debugged using standard tooling in devtools. Specifically the animation panel can be used to pause and scrub through the default animations set by the browser.
The pseudo DOM structure generated by the UA can also be inspected and targeted, like other DOM elements, in the style panel.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?No
Currently no support for Android WebView. This is WIP.Yes
Requires code in //chrome?False
|OriginTrial desktop last||107|
|OriginTrial desktop first||104|
|OriginTrial Android last||107|
|OriginTrial Android first||104|
Link to entry on the Chrome Platform Statushttps://chromestatus.com/feature/5193009714954240
Links to previous Intent discussionsIntent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/7SMI3IklO4g/m/JS-JojxNAwAJ