Intent to ship: Element.animate

[Brian Birtles]

In Firefox 48 I intend to turn Element.animate on by default.

We have been developing the Web Animations API behind the
dom.animations-api.core.enabled preference and have introduced the
dom.animations-api.element-api.enabled preference for the subset of the
API that we intend to ship at this time.

Chrome have been shipping a very similar subset of the API starting with
Chrome 36[1] and have recently updated their implementation to match the
subset we plan to ship.[2]

WebKit[3] and Edge[4] both list this as "under consideration" although
some implementation work has begun in WebKit.[5]

This feature was previously discussed in this "intent to implement"
thread:
https://groups.google.com/d/topic/mozilla.dev.platform/3EXBgp26rJs/discussion

Bug to turn on by default:
https://bugzilla.mozilla.org/show_bug.cgi?id=1245000
Link to standard:
https://w3c.github.io/web-animations/#dom-animatable-animate

The subset of the API we intend to ship is described in the bug above, a
summary of which I have copied to the end of this mail. We do not intend
to ship the 'finished' promise at this time due to concern that this
should use a cancelable promise.[6]

Best regards,

Brian

[1] https://www.chromestatus.com/features/4854343836631040,
https://www.chromestatus.com/features/5633748733263872
[2] https://www.chromestatus.com/features/5650817352728576,
https://www.chromestatus.com/features/5663463749713920
[3] https://webkit.org/status/#specification-web-animations
[4]
https://developer.microsoft.com/en-us/microsoft-edge/platform/status/webanimationsjavascriptapi
[5] https://lists.webkit.org/pipermail/webkit-dev/2015-November/027771.html
[6] https://github.com/w3c/web-animations/issues/141


Proposed API subset:

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

// 'Animation' will not be exposed on the global unless Element.animate
is called
interface Animation : EventTarget {
attribute DOMString id;
attribute double? startTime;
attribute double? currentTime;
attribute double playbackRate;
readonly attribute AnimationPlayState playState;
readonly attribute Promise<Animation> ready;
attribute EventHandler onfinish;
attribute EventHandler oncancel;
void cancel ();
void finish ();
void play ();
void pause ();
void reverse ();
};

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

enum PlaybackDirection {
"normal",
"reverse",
"alternate",
"alternate-reverse"
};

dictionary AnimationEffectTimingProperties {
double delay = 0.0;
double endDelay = 0.0;
FillMode fill = "auto";
double iterationStart = 0.0;
unrestricted double iterations = 1.0;
(unrestricted double or DOMString) duration = "auto";
PlaybackDirection direction = "normal";
DOMString easing = "linear";
};

// These members are read but not implemented
dictionary KeyframeEffectOptions : AnimationEffectTimingProperties {
IterationCompositeOperation iterationComposite = "replace";
CompositeOperation composite = "replace";
DOMString spacing = "distribute";
};

dictionary KeyframeAnimationOptions : KeyframeEffectOptions {
DOMString id = "";
};

[NoInterfaceObject]
interface Animatable {
Animation animate(object? frames,
optional (unrestricted double or
KeyframeAnimationOptions)
options);
};

Element implements Animatable;

[Anne van Kesteren]

On Mon, Apr 18, 2016 at 4:12 AM, Brian Birtles <bbir...@mozilla.com> wrote:
> We do not intend to
> ship the 'finished' promise at this time due to concern that this should use
> a cancelable promise.

\o/


--
https://annevankesteren.nl/

[smaug]

On 04/18/2016 05:12 AM, Brian Birtles wrote:
> In Firefox 48 I intend to turn Element.animate on by default.
>
> We have been developing the Web Animations API behind the dom.animations-api.core.enabled preference and have introduced the
> dom.animations-api.element-api.enabled preference for the subset of the API that we intend to ship at this time.
>
> Chrome have been shipping a very similar subset of the API starting with Chrome 36[1] and have recently updated their implementation to match the
> subset we plan to ship.[2]
>
> WebKit[3] and Edge[4] both list this as "under consideration" although some implementation work has begun in WebKit.[5]
>
> This feature was previously discussed in this "intent to implement" thread: https://groups.google.com/d/topic/mozilla.dev.platform/3EXBgp26rJs/discussion
>
> Bug to turn on by default: https://bugzilla.mozilla.org/show_bug.cgi?id=1245000
> Link to standard: https://w3c.github.io/web-animations/#dom-animatable-animate
>
> The subset of the API we intend to ship is described in the bug above, a summary of which I have copied to the end of this mail. We do not intend to
> ship the 'finished' promise at this time due to concern that this should use a cancelable promise.[6]

Does blink ship 'finished' promise?

Are there good wpt tests where we pass the same tests as other implementers?

>
> Best regards,
>
> Brian
>
> [1] https://www.chromestatus.com/features/4854343836631040, https://www.chromestatus.com/features/5633748733263872
> [2] https://www.chromestatus.com/features/5650817352728576, https://www.chromestatus.com/features/5663463749713920
> [3] https://webkit.org/status/#specification-web-animations
> [4] https://developer.microsoft.com/en-us/microsoft-edge/platform/status/webanimationsjavascriptapi
> [5] https://lists.webkit.org/pipermail/webkit-dev/2015-November/027771.html
> [6] https://github.com/w3c/web-animations/issues/141
>
>
> Proposed API subset:
>
> enum AnimationPlayState { "idle", "pending", "running", "paused", "finished" };
>
> // 'Animation' will not be exposed on the global unless Element.animate is called

What does this mean? Per spec 'Animation' should be exposed in the global.

[bbir...@mozilla.com]

On Tuesday, 19 April 2016 02:23:54 UTC+9, smaug wrote:
> On 04/18/2016 05:12 AM, Brian Birtles wrote:
> > In Firefox 48 I intend to turn Element.animate on by default.
> >
> > We have been developing the Web Animations API behind the dom.animations-api.core.enabled preference and have introduced the
> > dom.animations-api.element-api.enabled preference for the subset of the API that we intend to ship at this time.
> >
> > Chrome have been shipping a very similar subset of the API starting with Chrome 36[1] and have recently updated their implementation to match the
> > subset we plan to ship.[2]
> >
> > WebKit[3] and Edge[4] both list this as "under consideration" although some implementation work has begun in WebKit.[5]
> >
> > This feature was previously discussed in this "intent to implement" thread: https://groups.google.com/d/topic/mozilla.dev.platform/3EXBgp26rJs/discussion
> >
> > Bug to turn on by default: https://bugzilla.mozilla.org/show_bug.cgi?id=1245000
> > Link to standard: https://w3c.github.io/web-animations/#dom-animatable-animate
> >
> > The subset of the API we intend to ship is described in the bug above, a summary of which I have copied to the end of this mail. We do not intend to
> > ship the 'finished' promise at this time due to concern that this should use a cancelable promise.[6]
>
> Does blink ship 'finished' promise?

No. I've just discussed with them and we will also not ship the 'ready' promise either, for similar reasons.

> Are there good wpt tests where we pass the same tests as other implementers?

Yes. We've contributed a number of tests to wpt and the Chrome team are running them against blink and addressing issues that arise. We still have more tests to contribute though and a few of us are spending a lot of time on that at the moment.

> > // 'Animation' will not be exposed on the global unless Element.animate is called
> What does this mean? Per spec 'Animation' should be exposed in the global.

Full details are in bug 1245000 from comment 9 onwards (https://bugzilla.mozilla.org/show_bug.cgi?id=).

Initially we would like to release Animation as [NoInterfaceObject] because of compat concerns that other libraries might be using 'Animation'. Blink currently ships with [NoInterfaceObject] so we don't know yet if this interface name is Web compatible.

(Unlike blink, however, we have implemented the Animation constructor and, per-spec, implemented Element.animate() in terms of that constructor. Hence the slightly odd situation where Animation is not initially on the global but might be added if you call Element.animate().)

This is a temporary situation because I don't want to have to back out the whole Element.animate feature due to compat issues from the 'Animation' interface name. After we have shipped Element.animate we can ship the Animation constructor behind a different pref.

[Brian Birtles]

On Tuesday, 19 April 2016 09:29:02 UTC+9, bbir...@mozilla.com wrote:
> Full details are in bug 1245000 from comment 9 onwards (https://bugzilla.mozilla.org/show_bug.cgi?id=).

Err, https://bugzilla.mozilla.org/show_bug.cgi?id=1245000#c9.

[smaug]

That doesn't sound like a behavior we should ship. Either make it [NoInterfaceObject] or normal interface.
And if it needs to be [NoInterfaceObject], constructor shouldn't be supported.

>
> This is a temporary situation because I don't want to have to back out the whole Element.animate feature due to compat issues from the 'Animation'
> interface name. After we have shipped Element.animate we can ship the Animation constructor behind a different pref.

Why would you need to backout animate() if the interface was [NoInterfaceObject] ?


So could we ship constructor + removing [NoInterfaceObject] as a separate step, not when shipping this initial API? And have [NoInterfaceObject] until
that. If we're worried about web-compatibility, the API spec editors should consider changing the spec to be more likely web-compatible, and better to
do that before anyone supports the constructor (since I assume it might mean changing the interface name)



-Olli

[smaug]

In other words, ok to ship from here, but not with the odd [NoInterfaceObject] + constructor setup.



>
>
> -Olli
>
>

[bbir...@mozilla.com]

On Tuesday, 19 April 2016 22:03:48 UTC+9, smaug wrote:
> > This is a temporary situation because I don't want to have to back out the whole Element.animate feature due to compat issues from the 'Animation'
> > interface name. After we have shipped Element.animate we can ship the Animation constructor behind a different pref.
> Why would you need to backout animate() if the interface was [NoInterfaceObject] ?

This was referring to the alternative of shipping the constructor under the same pref as the rest of the Element.animate implementation. If we do that and compatibility issues with 'Animation' arise late in the game, we'd have to turn off the pref and effectively unship the whole Element.animate feature.

> So could we ship constructor + removing [NoInterfaceObject] as a separate step, not when shipping this initial API? And have [NoInterfaceObject] until
> that. If we're worried about web-compatibility, the API spec editors should consider changing the spec to be more likely web-compatible, and better to
> do that before anyone supports the constructor (since I assume it might mean changing the interface name)

We could, however we have quite a few tests that rely on this constructor so we'd end up being unable to test a lot of things. I wouldn't want to make it [NoInterfaceObject] on trunk, at least, but perhaps we could do that on aurora/beta, for example.

If we do discover compatibility issues, I'll gladly update the spec. And just to clarify, there are no specific compatibility issues that I am aware of--just the fact the Animation is a fairly generic name.


At this point it seems like it depends on how likely we are to hit compatibility issues. I'll see if the blink folks have any data on this. If it seems like the compatibility risk is low, then we should just ship the constructor from the start and take the risk that we might have to disable Element.animate.