*LGTM* to extend the experiment till M96 (inclusive) On Mon, Aug 30, 2021 at 7:09 PM Vladimir Levin <[email protected]> wrote:
> Contact [email protected], [email protected], > [email protected], [email protected] > > Explainer > https://github.com/vmpstr/shared-element-transitions/blob/main/README.md > > 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). 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. > > > Blink componentBlink>Animation > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EAnimation> > > TAG reviewhttps://github.com/w3ctag/design-reviews/issues/631 > > TAG review statusPending > > Risks > > > 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 signal > > WebKit: No signal > > Web developers: Positive Interest in the feature: > https://twitter.com/jaffathecake/status/1386673316354797570 Main feedback > is requests to provide more customizability and power: > https://github.com/WICG/shared-element-transitions/issues/28 > https://github.com/WICG/shared-element-transitions/issues/9 > > Ergonomics > > None. > > > Activation > > Low. 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. > > > Security > > The current implementation handles transitions in Viz in anticipation of > MPA scenarios. More details on this are outlined in the design doc. 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 > > > Goals for experimentation > > The API shape is currently limited, providing only a stock set of > transition types. We've already seen engagement on the WICG and a desire > for more customization (see web developer response). We hope to learn more > about the utility of the default transition types and experiences partners > would like to create, but are unable to achieve with the limited API (we > have two external partners who have indicated interest). Based on that > feedback, we may make changes to the API to add more customization. We also > want to know how easy it is to adopt this API on an existing site. > > > Reason this experiment is being extended > > We have gathered feedback from partners, but some amendments to the > feature are needed in order for them to utilize the feature. Specifically, > easing function, duration, and delay controls for shared elements is needed > to better animation control. We are working on adding the controls and > would like to extend the experiment. Original experiment start date: M92 > Original experiment end date: M94 Proposed new end date: M96 > > > Ongoing technical constraints > > None. > > > Debuggability > > It is possible to set breakpoints inside post-preparation and > post-transition handlers, but beyond this there is no way, presently, to > debug an unexpected transition. Specifically, there currently is no way to > scrub through a transition, or to inspect the shared/transitioned elements. > These are potential areas for improvement if we get developer feedback that > these would be helpful. > > > 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. WebView presents challenges due > to its rendering architecture. > > > Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> > ?No > > Flag nameDocumentTransition > > Requires code in //chrome?False > > Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1150461 > > Estimated milestones > OriginTrial desktop first 92 > OriginTrial desktop last 96 > OriginTrial android first 92 > OriginTrial android last 96 > > Link to entry on the Chrome Platform Status > https://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 > Intent to Experiment: > https://groups.google.com/a/chromium.org/g/blink-dev/c/UgZAAElUWzU > > > This intent message was generated by Chrome Platform Status > <https://www.chromestatus.com/>. > > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2PmRbP8g0UzsjHdZjv%2B5kjfhTb3fy1%2B%2BCaejM5EYKRZ_g%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2PmRbP8g0UzsjHdZjv%2B5kjfhTb3fy1%2B%2BCaejM5EYKRZ_g%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVhyZ%2BNf8bCuiGPCj_D6HG30POWueYyWMA9SsyMa0y6pw%40mail.gmail.com.
