Intent to Ship: Element.animate

639 views
Skip to first unread message

Douglas Stockwell

unread,
Apr 15, 2014, 9:17:34 PM4/15/14
to blink-dev

Contact emails

dstoc...@chromium.orgsh...@chromium.org

Spec

Editor’s draft[1]

 

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. The specification is progressing and we expect[2] a second working draft to be published in the near future. In Blink we have completed[3] the migration of CSS Animations and Transitions to the Web Animations model and have implemented significant parts of the API behind runtime feature flags.

To motivate other implementations and solicit wider feedback in order to help progress the specification effort we would like to enable a minimal subset of the Web Animations API at this time. We propose to begin by adding the ability for script to programmatically start and cancel declarative animation. Note that this is a smaller subset than the initial stages discussed at the last face to face meeting[4]. This small subset of Element.animate provides functionality similar to CSS Animations including off main-thread animation, but in a form that’s significantly more accessible to script.

Our intention is to work towards the entire first stage 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.

The exact API we plan to enable at this time is currently guarded behind the WebAnimationsElementAnimate[5] runtime feature flag, as summarised by the following IDL snippet:

partial interface Element {

    AnimationPlayer animate(

        sequence<Keyframe> effect,

        optional (double or TimingInput) timing);

}

[NoInterfaceObject]

interface AnimationPlayer : EventTarget {

    void cancel ();

    attribute EventHandler onfinish;

};

dictionary Keyframe {

    // ... property-value pairs ...

    double? offset = null;

    DOMString easing = "linear";

};

dictionary TimingInput {

    double delay = 0;

    double endDelay = 0;

    FillMode fill = "auto";

    double iterationStart = 0.0;

    unrestricted double iterations = 1.0;

    (unrestricted double or DOMString) duration = "auto";

    double playbackRate = 1.0;

    PlaybackDirection direction = "normal";

    DOMString easing = "linear";

};

enum FillMode { "none", "forwards", "backwards", "both", "auto" };

Note that the names Keyframe, TimingInput and FillMode are not exposed to script, they only serve to type the input. AnimationPlayer is not marked [NoInterfaceObject] in the full API, but doing so here helps to mitigate future naming changes.

Link to “Intent to Implement” blink-dev discussion

Link to the blink-dev discussion about implementation: Intent to Implement: Web Animations JavaScript API[6]

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

Yes.

Demo link

Native[7] (runs on trunk with experimental web platform features enabled)

Polyfill[8]

Compatibility Risk

This is a new feature and Blink will be the first rendering engine to enable it. We believe this feature to be stable and a sensible addition 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.

There is a risk that adding ‘animate’ to Element may break content that uses ‘animate’ in inline script attributes. We expect this to be similar to other additions to Element[9] and plan to work through any issues encountered during time in Chrome’s Dev and Beta channels. In anticipation we added a no-op version of animate in r171017[10]

The current status among other rendering engines:

Gecko[11]:

Preparatory work has begun. The current focus is towards moving existing CSS Animations and Transitions to the Web Animations model.

WebKit[12] [13]:

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

Internet Explorer[14]:
“under consideration”

OWP launch tracking bug?

crbug.com/257235

Link to entry on the feature dashboard

Web Animations JavaScript API[15]


Rik Cabanier

unread,
Apr 15, 2014, 10:56:05 PM4/15/14
to Douglas Stockwell, blink-dev
On Tue, Apr 15, 2014 at 6:17 PM, Douglas Stockwell <dstoc...@chromium.org> wrote:

Contact emails

dstoc...@chromium.orgsh...@chromium.org

Spec

Editor’s draft[1]

 

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. The specification is progressing and we expect[2] a second working draft to be published in the near future. In Blink we have completed[3] the migration of CSS Animations and Transitions to the Web Animations model and have implemented significant parts of the API behind runtime feature flags.

To motivate other implementations and solicit wider feedback in order to help progress the specification effort we would like to enable a minimal subset of the Web Animations API at this time. We propose to begin by adding the ability for script to programmatically start and cancel declarative animation. Note that this is a smaller subset than the initial stages discussed at the last face to face meeting[4]. This small subset of Element.animate provides functionality similar to CSS Animations including off main-thread animation, but in a form that’s significantly more accessible to script.

Our intention is to work towards the entire first stage 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.


This is great news! I'm excited to see this going in.
 

The exact API we plan to enable at this time is currently guarded behind the WebAnimationsElementAnimate[5] runtime feature flag, as summarised by the following IDL snippet:

partial interface Element {

    AnimationPlayer animate(

        sequence<Keyframe> effect,

        optional (double or TimingInput) timing);

}

[NoInterfaceObject]

interface AnimationPlayer : EventTarget {

    void cancel ();


Is there a reason the play and pause APIs were not included?
Maybe there's another way to start and stop an animation?
 

    attribute EventHandler onfinish;


Could this become a promise and so we can rely on microtasks to provide synchronization?
If an author has to rely on event handlers to accomplish this, it's very hard if not impossible,
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Domenic Denicola

unread,
Apr 16, 2014, 12:48:23 AM4/16/14
to blin...@chromium.org


On Tuesday, April 15, 2014 9:17:34 PM UTC-4, Douglas Stockwell wrote:

    attribute EventHandler onfinish;


Is this event fired more than once, ever, or only once for each AnimationPlayer?

Is it useful for developers using AnimationPlayer to be able to tell if the animation is finished, independently of wanting to be notified when it is finished? (I.e., is it useful to be able to do post-facto checking?)

 

    double delay = 0;

    double endDelay = 0;


Could these become milliseconds, instead of seconds, to better align with normal JavaScript APIs like Date.now(), setTimeout, geolocation, etc.?

Boris Zbarsky

unread,
Apr 16, 2014, 1:50:07 AM4/16/14
to blink-dev
On 4/15/14 9:17 PM, Douglas Stockwell wrote:
> This intent covers only the parts detailed below, we plan to send additional
> intents for other parts of the API.

Douglas,

I'm a bit concerned, because as far as I can tell the part of the API
you propose to enable doesn't have a clearly defined processing model in
the web animations spec (see my mail to that list just now). Is the
processing model you implemented described somewhere?

-Boris

Shane Stephens

unread,
Apr 16, 2014, 2:31:16 AM4/16/14
to Boris Zbarsky, blink-dev
Hi Boris,

As I described on public-fx@, I think there is a 'natural' interpretation of the processing model (namely, the order of iteration in step 7 should match the order explicitly defined in step 9; and arguments should be processed in order from first to last). Our implementation matches this natural interpretation (if it doesn't, that's a bug), and we'll ensure that the specification includes normative text to define this well before our implementation reaches stable.
 
I think it's also worth pointing out that we are willing to accept the risk that we might need to change our processing model. Inputs that trigger the processing-order-dependent behavior you are describing are very unlikely to be popular uses of the API (indeed I suspect one must craft them reasonably carefully to demonstrate the differences at all), so I don't anticipate issues in making changes that upset the ordering defined above.

Cheers,
    -Shane



-Boris


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

Douglas Stockwell

unread,
Apr 16, 2014, 2:38:03 AM4/16/14
to Rik Cabanier, Domenic Denicola, blink-dev
Thanks for the feedback everyone!

Merging replies, see inline.

On Wed, Apr 16, 2014 at 12:56 PM, Rik Cabanier <caba...@gmail.com> wrote:

interface AnimationPlayer : EventTarget {

    void cancel ();


Is there a reason the play and pause APIs were not included?
Maybe there's another way to start and stop an animation?

The chosen subset is mainly that which is exposed via CSS. Although CSS essentially supports play/pause it has less capability for observing the current state of the animation. We want to be sure that the playback control parts of AnimationPlayer are compatible with off main-thread animation before we expose these features.
 

    attribute EventHandler onfinish;


Could this become a promise and so we can rely on microtasks to provide synchronization?
If an author has to rely on event handlers to accomplish this, it's very hard if not impossible,

Finish events are intended to support cleanup rather than synchronization. In the long term we expect synchronization to be achieved through use of animation groups and effect callbacks.

On Wed, Apr 16, 2014 at 2:48 PM, Domenic Denicola <dom...@domenicdenicola.com> wrote:
On Tuesday, April 15, 2014 9:17:34 PM UTC-4, Douglas Stockwell wrote:

    attribute EventHandler onfinish;


Is this event fired more than once, ever, or only once for each AnimationPlayer?

In the exposed subset the event would only be fired once. Once playback control is exposed it is possible for the event to fire multiple times for the same player.
 
Is it useful for developers using AnimationPlayer to be able to tell if the animation is finished, independently of wanting to be notified when it is finished? (I.e., is it useful to be able to do post-facto checking?)

Yes, and in the full AnimationPlayer interface there is a 'finished' attribute.
 

    double delay = 0;

    double endDelay = 0;

Could these become milliseconds, instead of seconds, to better align with normal JavaScript APIs like Date.now(), setTimeout, geolocation, etc.?

This has been discussed on several occasions, for example here[1]. Some arguments for the choice of seconds include aligning with other media and animation APIs, for example HTMLMediaElement and CSS Animation events.

Elliott Sprehn

unread,
Apr 16, 2014, 2:45:32 AM4/16/14
to Douglas Stockwell, Rik Cabanier, Domenic Denicola, blink-dev

On Wed, Apr 16, 2014 at 2:38 AM, Douglas Stockwell <dstoc...@chromium.org> wrote:
...

 

    attribute EventHandler onfinish;


Could this become a promise and so we can rely on microtasks to provide synchronization?
If an author has to rely on event handlers to accomplish this, it's very hard if not impossible,

Finish events are intended to support cleanup rather than synchronization. In the long term we expect synchronization to be achieved through use of animation groups and effect callbacks.


Note also that events can fire whenever we want. There's nothing special about end of micro task or Promises.

- E

Boris Zbarsky

unread,
Apr 16, 2014, 2:48:48 AM4/16/14
to Shane Stephens, blink-dev
On 4/16/14 2:31 AM, Shane Stephens wrote:
> As I described on public-fx@, I think there is a 'natural'
> interpretation of the processing model (namely, the order of iteration
> in step 7 should match the order explicitly defined in step 9

Actually, that part makes no sense to me, as I said in my response on
the list.... Unless it's a proposal to completely change the processing
model there from the one currently in the spec, of course. Which might
be fine, but would be good to get sorted out before we start shipping
things.

> and arguments should be processed in order from first to last

See my mail to the list.

> Our implementation matches this natural interpretation

Then your implementation is not implementing the WebIDL in the spec.

> and we'll ensure that the specification includes
> normative text to define this well before our implementation reaches stable.

I'd be more comforted if you weren't telling me that you plan to change
the spec to match whatever your implementation happens to be doing... or
at least if I knew what your implementation is really doing. ;)

-Boris

Shane Stephens

unread,
Apr 16, 2014, 2:57:36 AM4/16/14
to Boris Zbarsky, blink-dev
I didn't mean to imply that :) 

I misunderstood the issue you were presenting. We'll get the spec sorted and the implementation fixed (if it needs to change) before our implementation hits stable. I don't anticipate the changes being very difficult or user-visible, do you concur?

Cheers,
    -Shane
 


-Boris

Boris Zbarsky

unread,
Apr 16, 2014, 3:06:15 AM4/16/14
to Shane Stephens, blink-dev
On 4/16/14 2:57 AM, Shane Stephens wrote:
> I don't anticipate the changes being very
> difficult or user-visible, do you concur?

Yes. Thanks in advance for making them happen!

-Boris

Brian Birtles

unread,
Apr 16, 2014, 3:40:47 AM4/16/14
to blin...@chromium.org, Rik Cabanier, Domenic Denicola

On Wednesday, April 16, 2014 3:38:03 PM UTC+9, Douglas Stockwell wrote:

    double delay = 0;

    double endDelay = 0;


Could these become milliseconds, instead of seconds, to better align with normal JavaScript APIs like Date.now(), setTimeout, geolocation, etc.?

This has been discussed on several occasions, for example here[1]. Some arguments for the choice of seconds include aligning with other media and animation APIs, for example HTMLMediaElement and CSS Animation events.


I'd still be very interested if anyone else has additional data points on this. There may be more APIs that have been minted since we last did a survey that swing the balance and getting this wrong could be a real paint point for authors.

Domenic Denicola

unread,
Apr 16, 2014, 9:21:04 AM4/16/14
to Brian Birtles, blin...@chromium.org, Rik Cabanier
My personal surprise at seeing seconds instead of milliseconds comes from extensive use of jQuery and d3 to do animations, both of which use milliseconds.

In general I think using seconds in an API exposed to JavaScript is non-idiomatic and am sad a few specs have started down a bad path. I hope they don't drag web animations along with them down that path.

From: Brian Birtles
Sent: ‎4/‎16/‎2014 3:40 AM
To: blin...@chromium.org
Cc: Rik Cabanier; Domenic Denicola
Subject: Re: [blink-dev] Intent to Ship: Element.animate

Adam Barth

unread,
Apr 16, 2014, 9:54:27 AM4/16/14
to dom...@domenicdenicola.com, bbir...@mozilla.com, blin...@chromium.org, caba...@gmail.com
This sort of detail-oriented issue is better discussed in the working group where all the interested parties can participate on an equal footing.

Adam


On Wed Apr 16 2014 at 6:21:10 AM, Domenic Denicola <dom...@domenicdenicola.com> wrote:
My personal surprise at seeing seconds instead of milliseconds comes from extensive use of jQuery and d3 to do animations, both of which use milliseconds.

In general I think using seconds in an API exposed to JavaScript is non-idiomatic and am sad a few specs have started down a bad path. I hope they don't drag web animations along with them down that path.

From: Brian Birtles
Sent: 4/16/2014 3:40 AM

To: blin...@chromium.org
Cc: Rik Cabanier; Domenic Denicola
Subject: Re: [blink-dev] Intent to Ship: Element.animate

Eric Seidel

unread,
Apr 17, 2014, 7:03:39 PM4/17/14
to Douglas Stockwell, blink-dev
It sounds like the earlier questions have been resolved. Thank you
very much for such a detailed email and responses.

Being the first to ship a new feature always assumes more risk than
being second. Especially when there is no fully-agreed on standard
yet. If the standard settles on something different either we will
have to change, or if usage of our implementation is high enough,
developers will have to UA sniff or the final standard will have to
use different API names. None of these are good outcomes (hence the
risk).

Given the recent notes from the face-to-face, it sounds like shipping
this minimal subset is about as low as we can hope it to be.

I’m extremely excited to see a simpler Animations API for the web.
It’s been way too hard [1] to do accelerated animations from JS for
way too long. Making animations easy (and easy to make accelerated)
is critical to providing compelling mobile user experiences on the
web.

Please be sure to continue to coordinate with other browser so that
developers have a hope of writing Web Animations which work across all
browsers in the near future.

I believe the importance of this feature to the web outweighs the
potential short-term risk to Blink, thus LGTM.

1. http://css-tricks.com/controlling-css-animations-transitions-javascript/

On Tue, Apr 15, 2014 at 6:17 PM, Douglas Stockwell
<dstoc...@chromium.org> wrote:

Adam Barth

unread,
Apr 17, 2014, 7:20:58 PM4/17/14
to Eric Seidel, Douglas Stockwell, blink-dev
LGTM2

Darin Fisher

unread,
Apr 17, 2014, 9:58:27 PM4/17/14
to Adam Barth, blink-dev, Douglas Stockwell, Eric Seidel

LGTM

Message has been deleted

Renée Wright

unread,
May 24, 2014, 8:45:08 PM5/24/14
to archan...@gmail.com, blink-dev
Hi Archana,

I just tested out your example with "ease-in"/"ease-out", and it worked with a few alterations (I needed to put the keyframe into a list, and add another keyframe. Web Animations doesn't work with single keyframes yet).

More generally, Element.animate(...) should work with ease, ease-in, ease-out, ease-in-out, linear, cubic-bezier(...), step-start, step-end, and steps(...).

What version of Chrome are you using? May we see the code that uses "linear" and works?

Renee.


On Sun, May 25, 2014 at 8:31 AM, <archan...@gmail.com> wrote:
I tried using easing as one of the options. 
  $('.green-box').animate({
          left: '540px'
        }, {
          duration: 1500,
          easing: 'linear'
        })

easing seems to accept only linear and not "ease-in" / "ease-out" etc. What are the values I can use with .animate()

Archana 

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

Reply all
Reply to author
Forward
0 new messages