Intent to Ship: Web Animations Level 1 interop

[Suzy Howlett]

Contact emails

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

Spec

Editor’s draft

Tag review

Summary

Having previously shipped a subset of the Web Animations level 1 API, we are now attempting to align with changes to the spec that will ship in Firefox. This involves implementing a small number of new APIs and minor changes to behavior, as listed below, to be completed by M51.

Release plan

M50

• Cancel events

• Animation.id

• Lists of values in keyframes

• pause() moves from idle to the paused state

• Deprecate dashed-names as keys in keyframes

M51

• Remove dashed-names as keys in keyframes

In addition, we will

• Upstream Blink tests to https://github.com/w3c/web-platform-tests

• Implement the above features in the polyfill, as an optional module that uses separate checks for deciding to fallback to the native implementation. This avoids an all-or-nothing fallback for a period where browser implementations are incomplete.

Link to “Intent to Implement” blink-dev discussion

Intent to Implement: Web Animations JavaScript API

Previous partial intents to ship:

• Intent to Ship: Element.animate

• Intent to Ship: Web Animations Playback Control

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

Yes

Debuggability

Supported in DevTools animation inspection: https://code.google.com/p/chromium/issues/detail?id=447083

Interoperability and Compatibility Risk

This change improves interop by bringing Blink's implemented subset of Web Animations level 1 into line with Gecko and the spec.

Gecko: Preparing to ship: https://bugzilla.mozilla.org/show_bug.cgi?id=1245000 https://birtles.github.io/areweanimatedyet/

WebKit: Under development: http://webkit.org/b/122912 https://lists.webkit.org/pipermail/webkit-dev/2015-November/027771.html

Edge: Under consideration, development is likely in future: http://status.modern.ie/webanimationsjavascriptapi

OWP launch tracking bug

http://crbug.com/257235

Entry on the feature dashboard

https://www.chromestatus.com/feature/5650817352728576

[Chris Harrelson]

Hi Suzy,

Could you summarize the degree of risk in the breaking changes listed here? Could they break existing pages, and how? How often do you expect this would happen?

Thanks,

Chris

--
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.

[Suzy Howlett]

Hi Chris,

Cancel events, Animation.id, and lists of values in keyframes are new features, so would not introduce any breaking changes. The change to pause() is to fix a bug in a state that is, as I understand it, difficult to get into.

For the dashed-names in keyframes, adding a deprecation warning will add a UseCounter that we can use to collect more detailed usage information. But at this stage, Element.animate as a whole has a low usage, and the major user Polymer does not use dashed-names, so deprecating this name format is a low risk change.

Suzy

[Elliott Sprehn]

This is very exciting. What about getAnimations() ?

Without that API I find developers do fill: 'forward' and then can't figure out where the forced style changes come from later... or they cause infinite memory usage.

[Douglas Stockwell]

There isn't infinite memory usage, our implementation collapses filling values so as to avoid leaking. Until we ship getAnimations the recommendation is to retain the Animation objects so that the effect can be cancelled at the appropriate time.

We need to finalize the exposure of CSS Animations and Transitions before we can ship getAnimations(). We have recently discussed how to expose only a summary of fill:forward state via getAnimations in order to allow fill:forwards effects to be removed.

- Doug

[Elliott Sprehn]

Great!

[PhistucK]

On Thu, Feb 11, 2016 at 7:04 AM, Douglas Stockwell <dstoc...@chromium.org> wrote:

We need to finalize the exposure of CSS Animations and Transitions

It would be great if you elaborate on that note.

☆PhistucK

[Shane Stephens]

CSS Animations and Transitions are intended to map into the list of animations returned by getAnimations. This is non-trivial and we are still cleaning up issues (e.g. what parts of the mapping should be read-only? What filtering options should be available?). We'd like to get this right before shipping anything, as CSS contributed animations suddenly showing up in a shipped list of animations are likely to break pages.

Cheers,

    -Shane

--

[Chris Harrelson]

LGTM1, with the specified target milestones.

Please merge a UseCounter for dashed names into M50 as well.

[Dimitri Glazkov]

LGTM2

[Philip Jägenstedt]

LGTM2

[Alex Russell]

LGTM3+

[Suzy Howlett]

Hi folks,

An update on where we are with this Intent:

The following changes were completed in time for M50:

• Cancel events
  
• Animation.id
  

• pause() moves from idle to the paused state
  
• Deprecate dashed-names as keys in keyframes
  

The work on supporting lists of values and iterable objects in the frames argument was not completed by the branch point and so will be pushed back to M51.

I have updated the chromestatus entry https://www.chromestatus.com/feature/5650817352728576 and created a second chromestatus entry for the features that will be in M51: https://www.chromestatus.com/feature/5663463749713920.

[Joe Medley]

On Wed, Mar 2, 2016 at 4:53 PM, Suzy Howlett <su...@chromium.org> wrote:

created a second chromestatus entry for the features that will be in M51: https://www.chromestatus.com/feature/5663463749713920.

😀

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.