Intent to Ship: Support for web-animations-1 JavaScript API.

[Kevin Ellis]

Contact emails kev...@chromium.org Explainer Draft of detailed explainer: https://docs.google.com/document/d/1sWAEytrZDxQWnnqozMSzI2lHvIJ0kF3dzgy9Q1PbYjE/edit?usp=sharing https://developer.mozilla.org/en-US/docs/Web/API/Web_Animations_API https://developer.mozilla.org/en-US/docs/Web/API/Animation/timeline https://developer.mozilla.org/en-US/docs/Web/API/EffectTiming/fill https://css-tricks.com/additive-animation-web-animations-api/ https://developer.mozilla.org/en-US/docs/Web/API/Web_Animations_API/Using_the_Web_Animations_API Spec https://drafts.csswg.org/web-animations-1/ TAG review Summary Update the web animations JavaScript API to align with the specifications in https://drafts.csswg.org/web-animations-1/. The Animation interface is extended to include support for the ready and finished promises, replaceable animations, and read-only access to the animation timeline. The Animatable and DocumentOrShadowRoot interfaces are expanded to support getAnimations. The KeyframeEffect interface is expanded to support compositing modes, getKeyframes, setKeyframes, and pseudoElement. Link to “Intent to Prototype” blink-dev discussion https://groups.google.com/a/chromium.org/d/msg/blink-dev/KF3Cwr_Kcl0/BSp04-_ERYkJ Risks

Interoperability and Compatibility Safari and Firefox have released support for web-animations-1. The extent of feature coverage across browsers is well tracked in web platform tests at https://wpt.fyi. The web platform test section below indicates the relevant sections. There are compat differences in the structure of commitStyles and transition keyframes. Transforms are resolved on Safari, computed on Firefox and will likely be a mix of the two on Chrome. Safari has deferred support for composite modes to a later release; however, there is cross browser agreement on the specifications for compositing modes. Firefox: Shipped (https://wpt.fyi/results/web-animations/interfaces?label=master&label=stable&product=firefox&aligned) Supported in Firefox 75 Edge: No public signals Safari: Shipped (https://wpt.fyi/results/web-animations/interfaces?label=master&label=stable&product=safari&aligned) Supported on Safari 13.1 macOS 10.14. Web developers: Positive (https://www.devbridge.com/articles/waapi-better-api-web-animations/) Ergonomics Spec changes resolving potential style conflicts when the web animations API is used on a CSS animation (https://drafts.csswg.org/css-animations-2/#animations) have only recently been resolved (March 5, 2020). Activation Already shipped on Safari and Firefox.

Debuggability * Animations tools in the element inspector. * Getters and setters in the animations API * Ability to query animations via getAnimations. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests? Yes https://wpt.fyi/results/web-animations * Tests functionality of the web animation API. https://wpt.fyi/results/css/css-animations * Tests interactions of CSS animations and the web-animations API https://wpt.fyi/results/css/css-transitions * Tests interactions of CSS transitions and the web-animations API Tracking bug http://crbug.com/978551 Demo links https://birtles.github.io/mozdev2019/ https://mozdevs.github.io/Animation-examples/ Link to entry on the Chrome Platform Status https://www.chromestatus.com/feature/5126405660606464

This intent message was generated by Chrome Platform Status.

[Brian Birtles]

Firstly, congratulations! This is great to see this happening and the three browser engines aligning closely on timing.

One question and one point of clarification, below.

2020年4月21日火曜日 23時07分28秒 UTC+9 Kevin Ellis:

Interoperability and Compatibility

Safari and Firefox have released support for web-animations-1. The extent of feature coverage across browsers is well tracked in web platform tests at https://wpt.fyi. The web platform test section below indicates the relevant sections. There are compat differences in the structure of commitStyles and transition keyframes. Transforms are resolved on Safari, computed on Firefox and will likely be a mix of the two on Chrome.

I'm curious about this difference. Do you mind filing a spec issue on this (or pointing me to the existing one if there is one?).

 

Safari has deferred support for composite modes to a later release; however, there is cross browser agreement on the specifications for compositing modes. Firefox: Shipped (https://wpt.fyi/results/web-animations/interfaces?label=master&label=stable&product=firefox&aligned) Supported in Firefox 75

Firefox is not yet shipping composite modes to release channels.

It is implemented and enabled by default in Nightly, but it was understood that Safari was not shipping composite modes yet so Firefox deferred shipping it.

I'm not aware of any particular reason to block shipping it in Nightly, so it could probably be shipped reasonably soon (perhaps even Firefox 77) if Chrome feels it is ready to ship, and after reviewing the relevant WPT.

Thanks,

Brian

[Kevin Ellis]

Hi Brian,
In response to you question about the compat differences for transform values, I'm adding a test for commitStyles to highlight the discrepancy:

 https://chromium-review.googlesource.com/c/chromium/src/+/2161700

Chrome is returning resolved values (i.e. matrix/matrix3d) for all transform values instead of computed values (e.g. scale, rotate, ...).  In isolation, the difference does not result in visual discrepancies; however, it could affect list interpolation in subsequent animations transitioning from the committed style as it would force a matrix fallback for the interpolation. We are in the process of switching to computed values, but at present, this is an unresolved issue (crbug.com/1057307).

Regards,

Kevin

[Robert Flack]

On Wed, Apr 22, 2020 at 5:41 PM 'Kevin Ellis' via blink-dev <blin...@chromium.org> wrote:

Hi Brian,
In response to you question about the compat differences for transform values, I'm adding a test for commitStyles to highlight the discrepancy:

 https://chromium-review.googlesource.com/c/chromium/src/+/2161700

Chrome is returning resolved values (i.e. matrix/matrix3d) for all transform values instead of computed values (e.g. scale, rotate, ...).  In isolation, the difference does not result in visual discrepancies; however, it could affect list interpolation in subsequent animations transitioning from the committed style as it would force a matrix fallback for the interpolation. We are in the process of switching to computed values, but at present, this is an unresolved issue (crbug.com/1057307).

I suggested we bring this up as a compat issue because last I tested Safari also seems to commit the resolved transforms so even once we resolve our behavior I think developers will still encounter this. We had added many tests already for computed transforms but unfortunately they were using the computedStyleMap API so not well tested cross browser - Kevin's new test will at least test this for commit styles. Another area where this comes up is for transition keyframes, we plan on adding a few tests for this as well.

Another area for compat concern is where transforms can only be expressed as partway through an interpolation, e.g. https://jsbin.com/rezomur/1/edit?css,js,output where Firefox currently seems to use an interpolatematrix function - I believe this is the CSSWG issue for this behavior.

  

Regards,

Kevin

On Wednesday, April 22, 2020 at 2:28:07 AM UTC-4 Brian Birtles wrote:

Firstly, congratulations! This is great to see this happening and the three browser engines aligning closely on timing.

One question and one point of clarification, below.

2020年4月21日火曜日 23時07分28秒 UTC+9 Kevin Ellis:

Interoperability and Compatibility

Safari and Firefox have released support for web-animations-1. The extent of feature coverage across browsers is well tracked in web platform tests at https://wpt.fyi. The web platform test section below indicates the relevant sections. There are compat differences in the structure of commitStyles and transition keyframes. Transforms are resolved on Safari, computed on Firefox and will likely be a mix of the two on Chrome.

I'm curious about this difference. Do you mind filing a spec issue on this (or pointing me to the existing one if there is one?).

 

Safari has deferred support for composite modes to a later release; however, there is cross browser agreement on the specifications for compositing modes. Firefox: Shipped (https://wpt.fyi/results/web-animations/interfaces?label=master&label=stable&product=firefox&aligned) Supported in Firefox 75

Firefox is not yet shipping composite modes to release channels.

It is implemented and enabled by default in Nightly, but it was understood that Safari was not shipping composite modes yet so Firefox deferred shipping it.

I'm not aware of any particular reason to block shipping it in Nightly, so it could probably be shipped reasonably soon (perhaps even Firefox 77) if Chrome feels it is ready to ship, and after reviewing the relevant WPT.

I don't think that there's any need to block shipping this part of the API based on our experience with it and the WPT results. However, we did want to raise this for the intent as a potential compat difference. Thanks for clarifying on Firefox's current position.

 

Thanks,

Brian

--
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 blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5c8a0e7a-d7dd-4740-b0e2-69aa923d5407%40chromium.org.

[sligh...@chromium.org]

LGTM1

Thanks to everyone who has made this possible. Very excited to see this launch!

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[sligh...@chromium.org]

As an aside, and because it came up in conversation, this API was reviewed at the TAG many years ago and changes were integrated as a result:

https://github.com/w3ctag/design-reviews/blob/master/2013/10/Web%20Animations.md

[Yoav Weiss]

LGTM2

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5c8a0e7a-d7dd-4740-b0e2-69aa923d5407%40chromium.org.

--

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 blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/db20ac8b-a4c4-43bf-a84d-f738ba4702f6%40chromium.org.

[Daniel Bratell]

LGTM3

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgwKn%3Dthh-%2B6%3DVLt_XabRtADbnZ-N1M%2B9LVH-dmkU4euw%40mail.gmail.com.

[Chris Harrelson]

Congratulations on this big milestone for animations!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/987994ff-85bd-16b4-ddf0-6169f2716a6e%40gmail.com.

[Rick Byers]

+1, great work!

Also some low-grade level of outstanding interop issues is to be expected for a launch of this complexity and magnitude. As long as there are WPT tests capturing the few known differences, I'm happy. :-)

On Wed, Apr 22, 2020 at 5:41 PM 'Kevin Ellis' via blink-dev <blin...@chromium.org> wrote:

--