Intent to Ship: Element.animate
Douglas Stockwell
Contact emails
dstoc...@chromium.org, sh...@chromium.org
Spec
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?
Link to entry on the feature dashboard
Web Animations JavaScript API[15]
Rik Cabanier
Contact emails
dstoc...@chromium.org, sh...@chromium.org
Spec
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;
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Domenic Denicola
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?)
Could these become milliseconds, instead of seconds, to better align with normal JavaScript APIs like Date.now(), setTimeout, geolocation, etc.?
Boris Zbarsky
> This intent covers only the parts detailed below, we plan to send additional
> intents for other parts of the API.
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
-Boris
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Douglas Stockwell
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,
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?)
Could these become milliseconds, instead of seconds, to better align with normal JavaScript APIs like Date.now(), setTimeout, geolocation, etc.?
Elliott Sprehn
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.
Boris Zbarsky
> 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
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
> Our implementation matches this natural interpretation
> and we'll ensure that the specification includes
> normative text to define this well before our implementation reaches stable.
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
-Boris
Boris Zbarsky
> I don't anticipate the changes being very
> difficult or user-visible, do you concur?
-Boris
Brian Birtles
On Wednesday, April 16, 2014 3:38:03 PM UTC+9, Douglas Stockwell wrote:
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
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
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.
To: blin...@chromium.org
Cc: Rik Cabanier; Domenic Denicola
Subject: Re: [blink-dev] Intent to Ship: Element.animate
Eric Seidel
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/
Adam Barth
Darin Fisher
LGTM
Renée Wright
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()ArchanaTo unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.