Intent to Implement: Web Animations JavaScript API

[Douglas Stockwell]

Contact emails

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

Spec

http://www.w3.org/TR/2013/WD-web-animations-20130625/ (W3C First Public Working Draft)

Summary

Expose an API allowing script to create, modify and control animations.

Motivation

The Web Animations model unifies CSS Animations and Transitions with SVG Animations. The API makes it possible to perform direct inspection and manipulation of Web Animations content, and hence CSS and SVG Animated content. The API also provides developers with a powerful set of techniques for procedural generation of animated content.

Compatibility Risk

Low. We’ll be following the standard launch process and don’t plan to ship by default until there is a compatible implementation or the spec is at Candidate Rec. Mozilla’s implementation tracking bug is here https://bugzilla.mozilla.org/show_bug.cgi?id=875219.

Minutes of most recent W3C meeting: http://lists.w3.org/Archives/Public/public-fx/2013AprJun/0236.html - broad support and desire for a ‘strong API’. Main concern was from Apple that this API seems large to deploy all at once.

A polyfill is also available: https://github.com/web-animations/web-animations-js

Ongoing technical constraints

None.

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

Yes.

OWP launch tracking bug?

http://crbug.com/257235

Row on feature dashboard?

Yes.

Requesting approval to ship?

No.

[Kenneth Rohde Christiansen]

Sounds fine to implement given the broad support. lgtm

--
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone +45 4294 9458 / E-mail kenneth at webkit.org

﹆﹆﹆

[Alexis Menard]

I think it's a very nice feature and would like it inside Blink.

This spec is really big for a first WD and I think we should gradually expose the concepts to the public (behind a flag of course) to gather the feedback from them as early as possible rather than implementing the whole thing before exposing it behind the flag. Driving animations programatically has always been a tricky problem in term of API and behaviours (based on my previous experience writing some animations API in Qt).

LGTM of course, you're requesting the implementation.

--
Software Engineer @
Intel Open Source Technology Center

[bru...@partner.samsung.com]

This is exciting stuff! I've read from the working draft specification that backwards compatibility with previous animation-related specifications (i.e. CSS3 Animations) shall be maintained. I wonder how do you guys plan to maintain it? Speaking about code architecture, shall these share the same code base at some point? All in all, LGTM.

[Paul Irish]

I'm concerned that there's been little (if any) developer feedback on this feature so far. 

For such a large feature with significant API surface area, I want to feel more confident that it meets developers needs for animation beyond what's available in CSS so far. Asking some key developers and projects is great way to confirm that our investment here is solving real developer problems, will deliver better performance and kill off more JS in the future.  Additionally, the API today is substantially different than how all JS animation libraries APIs are designed. 

I'd suggest asking for feedback from Greensock, TweenJS, jQuery, Paper.js and d3. 

Chrome DevRel would be happy to help make introductions.  I hope these discussions will help turn some important allys into advocates of the feature.

[addyo...@gmail.com]

I just wanted to second Paul's concerns. I haven't seen sufficient evidence that we've spoken to developers in the community familiar with the animation space for their feedback on the API. Not in lists not in the issue tracker for the web animations polyfill (https://github.com/web-animations/web-animations-js/issues). Imo, this is key to delivering something that improves on current options. 

[Divya Manian]

I think it would be great if we worked more on the spec to split it into separate specifications each targeting a specific phase (implement & ship phase 1, gather feedback from use and amend or expand on phase 2 based on uses and feedback, and iterate onwards for more phases till complete). 

I also think the spec would benefit from a direct tie-in to various use cases mentioned in the beginning when each feature is being expanded on, in some form of pseudo-code. Right now the lack of examples or explanation on how each of these timing models etc. help with the use cases make it really hard to understand the specification. 

- divya

[Brian Birtles]

Mozilla is also interested in how we can gradually expose the API. If you specific suggestions about this or comments on the spec, please send them along to publ...@w3.org, subject starting '[web-animations]'.

Reaching out to key developers would be a great help. Thank you. So far we've had some input from Raphaël, and the Element.animate interface is very similar to jQuery, but that's about all.

Thanks,

Brian

[Shane Stephens]

Hi Paul and Addy,

We'd welcome introductions to the Greensock, TweenJS, Paper.js and D3 teams.  Feedback about the API from them would be very valuable. It's probably better to point them to the polyfill (http://github.com/web-animations/web-animations-js) than to the specification.

We have been working with multiple product teams in Google to discover typical web application requirements regarding animations. We've also presented the API at The Graphical Web 2012, in a GDL video, at linux.conf.au, and in a number of blog posts and articles. The feedback from web developers has been overwhelmingly positive, albeit mostly via word-of-mouth / twitter.

Some other important points:

 * Web Animations is primarily a unification model - it seeks to enable CSS Animations, CSS Transitions, and SVG Animations to be expressed in terms of the same set of underlying primitives. A lot of the design decisions are directly drawn from existing web platform declarative animations APIs!

 * Three of these JavaScript animations libraries have direct and trivial mappings into the Web Animations API. Conversely, most (all?) of the Web Animations concepts have close analogues in one or more of these libraries. I don't see any substantial differences here.

 * These four animations libraries seem to be too different to each other to conclude that there is a coherent design aesthetic for JS animations libraries that Web Animations is departing from.  For example, TweenJS is unique in exposing chaining as an approach to constructing animations. Paper.js provides a frame callback and doesn't seem to support declarative animations at all.

 * We are working closely with the creator of Raphael.js, one of the earlier and very popular animations APIs on the web. Dmitry Baranovskiy is in fact one of the editors of the specification.

 * Web Animations doesn't compete with these APIs. In some cases it may enhance them, by providing direct javaScript access to animations that will run in the compositor rather than on the main thread.

 * The polyfill has been publicly available for months now, and we've presented in a number of fora and published multiple blog posts about it and the specification. The fact that the issue tracker isn't full of basic specification issues is, if anything, a sign that people are happy with our approach.

Divya:

We've looked at splitting the specification into phases before, in particular in response to feedback from Dean Jackson of Apple. There are some feature sets that we have successfully managed to split from the specification - <media> element integration will now be explored in a separate spec, as will extensions to the timing function model.

We also looked at splitting the model definition from the API. Unfortunately, it turns out that doing so has very real costs (in particular, keeping the two versions in synchronization as various parts move through WD and CR stages would be extremely difficult).

On the other hand, I think splitting the implementation into multiple phases and using feedback from each phase to help shape the progress of the specification is a great idea, and is something that my team is interested in doing. For example, we're currently concentrating on the parts of the model required to support CSS Transitions and Animations, and could certainly release just the subset of the API that deals with these parts in advance of building out SVG support. I guess this is one reason why starting to release parts of the API behind a flag is important to do soon :)

We do intend to provide more examples that demonstrate the use cases in the specification. We probably won't put these directly in the spec as we are trying to limit its size - do you think a technical note or similar would be acceptable?

Cheers,

    -Shane

[Mike Lawther]

On 25 July 2013 10:03, Shane Stephens <sh...@google.com> wrote:

We have been working with multiple product teams in Google to discover typical web application requirements regarding animations.

The Polymer team is one of these - we've been working with them closely to make sure the API (via the polyfill) meets their needs and expectations as they build out their library.

    mike

[Dimitri Glazkov]

LGTM to implement. Godspeed.

:DG<

[Thibault Imbert]

+1 on Paul and Addy's concerns. We (at Adobe) have been following the spec with interest and also believe the surface is large and going incremental with more user's feedback would be a good thing. 

[Max Heinritz]

For an update on Web Animations, check out Alan and Eric's recent talk at linux.conf.au 2014:

Slides: http://alancutter.github.io/web-animations-slides-lca-2014/#1

Video: http://mirror.linux.org.au/pub/linux.conf.au/2014/Tuesday/204-Web_Animations_-_Eric_Willigers_and_Alan_Cutter.mp4

[Tim Ansell]

On 23 January 2014 07:34, Max Heinritz <m...@chromium.org> wrote:

For an update on Web Animations, check out Alan and Eric's recent talk at linux.conf.au 2014:

Slides: http://alancutter.github.io/web-animations-slides-lca-2014/#1

Video: http://mirror.linux.org.au/pub/linux.conf.au/2014/Tuesday/204-Web_Animations_-_Eric_Willigers_and_Alan_Cutter.mp4

The video of the talk can also be found on YouTube at http://www.youtube.com/watch?v=F6gXkHM-gPU&list=SPmiuOcBMoxjfeNAuAAJEeLvc3TDqjaC1E&index=4

Tim 

[goo...@gmail.com]

The video talks about the web animation api being behind a flag? I am assuming this would be in chromium? I couldn't understand what he said at that moment. I would love to start even just playing with it in chromium is possible.

[PhistucK]

Go to chrome://flags/#enable-experimental-web-platform-features (copy and paste), enable it, relaunch the browser and try. I am not sure this is exposed yet, but I think it should be.

☆PhistucK

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

[Renée Wright]

Hey gooswa,

As PhistucK said, the Web Animations API is behind the enable-experimental-web-platform-features flag.

We haven't implemented the whole API yet, but a useable section of it should be available in the next Chrome Beta release.

So far we've done:

• Element.animate(...) method. It works with a list of keyframes and optional timing information, and returns an Animation object.
• Animation object constructor and document.timeline.play(...). So you can do document.timeline.play(new Animation(...)), which starts the animation and returns a Player object.
  
• Bindings for Player objects; so you can pause a player, get its source, and so on.
• Bindings for TimedItem (the superclass for Animation).
  
• Bindings for Timing, so you can get and set the timing properties of a TimedItem.

Here's a demo to give you some idea of the syntax. It doesn't do anything very interesting. The comments describe what it should do.

<!DOCTYPE html>

<style>

 #target1 { top: 10px; }

 #target2 { top: 220px; }

 .target {

    position: absolute;

    left: 10px;

    height: 200px;

    font-size: 25px;

    background-color: black;

 }

</style>

<div class='target' id='target1'>ANIMATION 1</div>

<div class='target' id='target2'>ANIMATION 2</div>

<script>

// Start an animation using Element.animate().

// After 2 iterations, change its playback direction to 'reverse'.

var target1 = document.getElementById('target1');

var animation1 = target1.animate(

    [

        {width: '200px', backgroundColor: 'green', offset: 0},

        {width: '1000px', backgroundColor: 'cyan', offset: 1},

    ],

    {duration: 2, iterations: 4, fill: 'both'});

setTimeout(function() { animation1.specified.direction = 'reverse'; }, 4000);

// Create an animation using new Animation() and play it using document.timeline.play().

// After 2 iterations, change its timing function to steps(6, end).

// After 3 iterations, pause it.

var target2 = document.getElementById('target2');

var animation2 = new Animation(

    target2,

    [

        {backgroundColor: 'red', width: '200px', offset: 0},

        {backgroundColor: 'purple', offset: 0.3},

        {backgroundColor: 'yellow', width: '1000px', offset: 1}

    ],

    {duration: 2, iterations: 4, fill: 'both'});

var player2 = document.timeline.play(animation2);

setTimeout(function() { player2.source.specified.easing = 'steps(6, end)'; }, 4000);

setTimeout(function() { player2.pause(); }, 6000);

</script>

[goo...@gmail.com]

Oh wow thanks!

This is great! What about if I built chromium on my own? Would it already be in there?

[Renée Wright]

You're welcome :)

It is already in the dev channel, yes.