Intent to Ship: Web Animations Playback Control

[Douglas Stockwell]

Contact emails

dstoc...@chromium.org, sh...@chromium.org

Spec

Editor’s draft[1]

Demo link

Playback control and trivial scrubbing: Native and Polyfill[2]

Summary

The Web Animations specification introduces a model that explains the execution of CSS Animations, CSS Transitions, SVG Animation, and exposes an API to give script similar capabilities. In Blink we have completed[3] the migration of CSS Animations and Transitions to the Web Animations model and have taken a first step of shipping element.animate[4].

We are continuing with our plan to work towards the entire first stage[5] of the Web Animations API while assessing developer feedback and the progress of other implementations. This intent covers only the parts detailed below, we plan to send additional intents for other parts of the API.

At this time we propose shipping additions to the AnimationPlayer interface to enable playback control. These additions will enable authors to build compelling animation experiences for users, for example scrubbing the current time of an animation based on other inputs like touch. Another new capability is synchronization and alignment of animations through setting start or current times. These new APIs unblock shipping the <marquee> element in Blink-in-JS[6].

The API masks complexity in rendering engines where some animations run asynchronously on a separate thread (in Blink, the “impl” thread of the Chromium Compositor). When using pause() for example, the time at which the animation can be stopped precisely may not be synchronously accessible by the calling thread. Instead, pause() transitions through the “pending” state where the current time is unresolved (null). Asynchronously, once the pause has been communicated to the other thread and the pause time is known, the current time will be resolved and the state will transition to “paused”.

The additions to the AnimationPlayer API we plan to enable are guarded by the WebAnimationsPlaybackControl[7] runtime feature flag, as summarised by the following IDL snippet:

enum AnimationPlayState { "idle", "pending", "running", "paused", "finished" };

attribute double? startTime;

attribute double? currentTime;

attribute double playbackRate;

readonly attribute AnimationPlayState playState;

void finish();

void play();

void pause();

void reverse();

Link to “Intent to Implement” blink-dev discussion

Intent to Implement: Web Animations JavaScript API[8]

Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes.

Compatibility Risk

These APIs are new and Blink will be the first rendering engine to enable them. We believe these features to be stable and sensible additions to the web platform, but as the first to ship are willing to accept the risk that the final form may change. The small surface area helps mitigate this risk.

The current status among other rendering engines:

Gecko[9]:

The current focus is towards moving existing CSS Animations and Transitions to the Web Animations model. AnimationPlayers for CSS Animations and Transitions are exposed via element.getAnimationsPlayers() in their experimental channel.

WebKit[10,11]:

Announced an intent to implement the Web Animations model, migrate CSS and SVG Animations, and internally expose parts of the API for testing purposes. No public signals since.

Internet Explorer[12]:

“under consideration”, no public signals.

OWP launch tracking bug?

http://crbug.com/396369

Link to entry on the feature dashboard

Web Animations Javascript API [playback control][13]

[1] http://dev.w3.org/fxtf/web-animations/

[2] http://goo.gl/9ceYDi

[3] https://groups.google.com/a/chromium.org/d/topic/blink-dev/rnqaos49JO8/discussion

[4] https://groups.google.com/a/chromium.org/d/topic/blink-dev/SWxBI0uPvUE/discussion

[5] http://lists.w3.org/Archives/Public/public-fx/2014JanMar/0099.html

[6] https://groups.google.com/a/chromium.org/d/topic/blink-dev/0cpgMaFnZIk/discussion

[7] https://src.chromium.org/viewvc/blink?view=rev&revision=181696

[8] https://groups.google.com/a/chromium.org/d/topic/blink-dev/KF3Cwr_Kcl0/discussion

[9] https://bugzilla.mozilla.org/show_bug.cgi?id=875219

[10] http://webkit.org/b/122912

[11] https://lists.webkit.org/pipermail/webkit-dev/2013-October/025758.html

[12] http://status.modern.ie/webanimationsjavascriptapi

[13] http://www.chromestatus.com/features/4854343836631040

[Erik Dahlström]

On Fri, 12 Sep 2014 02:42:53 +0200, Douglas Stockwell
<dstoc...@chromium.org> wrote:

> Contact emails
>
> dstoc...@chromium.org, sh...@chromium.org
>
> Spec
>

> Editor’s draft <http://dev.w3.org/fxtf/web-animations/>[1]

>
> Demo link
>
> Playback control and trivial scrubbing: Native and Polyfill

> <http://goo.gl/9ceYDi>[2]

I tried the demos and the native version looks rather blurry when
animating compared to the polyfill version. Is this a known bug, or is it
meant to look like that?


--
Erik Dahlstrom, Web Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group

[Douglas Stockwell]

On Fri Sep 12 2014 at 6:06:41 PM Erik Dahlström <e...@opera.com> wrote:

I tried the demos and the native version looks rather blurry when
animating compared to the polyfill version. Is this a known bug, or is it
meant to look like that?

You're right, there is a blur during the scale animation in the native version. I hadn't noticed as I was only testing on mobile and other high-dpi devices. The difference is that the native version is scaling a composited layer whereas the polyfill version is repainting every frame (although the polyfill will likely set will-change in the future).

This issue isn't specific to the new features -- I see it in M37 with CSS Animations http://jsfiddle.net/som6hkxd/. Adding Ali, who I recall did some work to reraster during transform animations.

[PhistucK]

It happens even if you pause the animation when the text is 'closer', in case it matters.

Perhaps still is a higher level question (or coming too late to the game), but... when I pause that animation, I look at the computed styles of the animated element and I cannot see anything related to the transform property. Is that expected? If one animates a translation, how would one find the position of an element (or use its computed style - the one that is shown, not the one that the Developer Tools feature currently shows)?

It seems like the Web Animations feature changes the style (or design, or look) of an element without changing its CSS, which (at least to me), looks like more magic and less primitives. I thought the Web Animations feature is supposed to explain CSS animations and transitions, but it seems to just make it more magical, which is kind of weird.

Does this make sense? Am I missing something?

☆PhistucK

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

[Alan Cutter]

On 12 September 2014 22:11, PhistucK <phis...@gmail.com> wrote:

It happens even if you pause the animation when the text is 'closer', in case it matters.

Perhaps still is a higher level question (or coming too late to the game), but... when I pause that animation, I look at the computed styles of the animated element and I cannot see anything related to the transform property. Is that expected? If one animates a translation, how would one find the position of an element (or use its computed style - the one that is shown, not the one that the Developer Tools feature currently shows)?

It seems like the Web Animations feature changes the style (or design, or look) of an element without changing its CSS, which (at least to me), looks like more magic and less primitives. I thought the Web Animations feature is supposed to explain CSS animations and transitions, but it seems to just make it more magical, which is kind of weird.

Does this make sense? Am I missing something?

This behaviour isn't unique to the new API, regular CSS Animations and Transitions don't appear in the inspector's computed style tab either. My guess is it only shows properties from matching style rules on the element, the rest are categorised as "inherited" despite some of them being the target of animations.

You can still query getComputedStyle() to see the final animated style of an element as usual with Web Animations.

[Douglas Stockwell]

On Fri Sep 12 2014 at 10:12:07 PM PhistucK <phis...@gmail.com> wrote:

Perhaps still is a higher level question (or coming too late to the game), but... when I pause that animation, I look at the computed styles of the animated element and I cannot see anything related to the transform property. Is that expected? If one animates a translation, how would one find the position of an element (or use its computed style - the one that is shown, not the one that the Developer Tools feature currently shows)?

This appears to be an issue in the developer tools. Selecting the element and executing getComputedStyle($0).transform shows the transform matrix for me. I see a grayed out transform value if I toggle 'show inherited properties'. I'm not sure why the inspector decides to label in this fashion. It appears to be a bug. If you take my CSS Animation example from above you should notice that the inspector behaves the same way.

 

It seems like the Web Animations feature changes the style (or design, or look) of an element without changing its CSS, which (at least to me), looks like more magic and less primitives. I thought the Web Animations feature is supposed to explain CSS animations and transitions, but it seems to just make it more magical, which is kind of weird.

There's no magic, the underlying implementation is exactly the same code that's driving CSS Animations.

[PhistucK]

Correct, sorry! Indeed a bug. Two bugs, I guess. 1. It is not an inherited property, but it is counted as one. 2. The computed style are updated in real time (select another element and then select the previous element and it will only then update the values).

Thank you for the clarification.

☆PhistucK

[PhistucK]

Not so. Like Douglas mentioned, it is just a bug and the Developer Tools feature indeed shows the computed properties, albeit not in real time. Toggle the inherited properties checkbox to see the values.

https://mdn.mozillademos.org/en-US/docs/Web/CSS/animation$samples/Cylon_Eye?revision=642009

☆PhistucK

[Douglas Stockwell]

On Fri Sep 12 2014 at 10:55:35 PM PhistucK <phis...@gmail.com> wrote:

Correct, sorry! Indeed a bug. Two bugs, I guess. 1. It is not an inherited property, but it is counted as one. 2. The computed style are updated in real time (select another element and then select the previous element and it will only then update the values).

I filed http://crbug.com/413630 for #1

[Ali Juma]

We currently re-raster at maximum scale at the start of a scale animation when impl-side painting is enabled, but only for combinations of scales and translations where at most one scale is animated, and only when rastering at maximum scale doesn't produce a layer that's larger than the window. (These restrictions were used for the sake of simplicity and to avoid excessive memory use.) When the rotation is removed, the text stays sharp (with impl-side painting enabled): http://jsfiddle.net/zp2fn9yh/

[Adam Barth]

LGTM

I'm excited to see Web Animations moving forward!

Adam

[Dimitri Glazkov]

LGTM2

[Elliott Sprehn]

Make it so.

[Ojan Vafai]

LGTM3