Web Animations

It must be time for my biannual blog post and this time I’d like to introduce a new development in animation for the Web, called, creatively enough, Web Animations.

Some of you may have heard rumblings of an attempt to overcome some of the limitations with both CSS and SVG animations and unify them at the same time. Well, that’s what some folks at Google, Adobe and myself (Mozilla) are trying to do.

I’ve put together a video of some of the ideas we have so far:



An in case the video gets synderadicated here’s a Youtube link: https://www.youtube.com/watch?v=VvNQNtIfXXI

If you’re interested in the details, the latest version of the spec is here:

https://dvcs.w3.org/hg/FXTF/raw-file/tip/web-anim/index.html

A few points to bear in mind:

  • There are still lots of holes. The behaviour of pausing and reversing is particularly in flux at the moment and the integration with media is still just thoughts, yet to be fleshed out and spec-ified.
  • The integration with CSS and SVG will be specified in separate documents (just placeholder text for now).
  • If you’ve got suggestions, please feel free to send feedback to the public-fx W3C mailing list with the subject [web-anim] at the start of the subject.
  • Progress from my end has slowed down recently due to some workshops I’ve been involved in but I’ll hopefully be back into it by the end of November.
  • We have a shim in the works (that’s what the video uses) but it’s currently awaiting approval for release. Should be ready soon.

7 Responses to “Web Animations”

  1. Javascriptless says:

    That’s nice, now as both SVG SMIL and CSS animations work with javascript disabled, can you show us code of that example “Web Animation” running with javascript disabled?

    Please tell us we haven’t gone backwards to javascript-based animations.

  2. Brian says:

    That’s the purpose of the SVG and CSS integration documents—they map declarative features onto the API. We intend to extend the capabilities of declarative animation in both SVG and CSS at the same time.

    I agree on the importance of support animation without script. One example is animated emoji in an SVG-in-OpenType font. You can’t run script there. Or cursors, backgrounds, cross-domain images etc. As someone who spent nearly 8 years implementing SMIL I’ve seen many benefits of a declarative approach. (I have a report emphasising that point.)

    Ultimately, the API is not the primary goal. It’s actually something we decided on after starting the spec. The goal is a consistent and more powerful model for animation on the Web. But having a scripting API lets you inspect declaratively generated animations, manipulate them (both SVG and CSS animation APIs are quite lacking at the moment), sync them (i.e. CSS<->SVG), test interop at a lower level (CSS animations are particularly hard to test at the moment), etc. For cases where script is appropriate, the API makes writing frame-rate independent synchronizable animations easier and hardware accelerate-able.

  3. ben says:

    Are you familiar with QML?

    It is (among other things) a declarative animation framework that is much more developer friendly than SMIL.

    Its development is currently tied to “offline” application UI development with Qt, but the language and declarative API itself should be easy to transpose into a web world.

  4. Brian says:

    @ben: I wasn’t familiar with QML so I had a look. It’s pretty nice. I think we have a pretty similar feature set, even down to matching the parallel and sequence animation types.

    The pause animation (i.e. spacer gif) is interesting and might be worth adding. So is the spring animation—although I think we can realise this at the API level with the proposed SmoothTimingFunc and then add some declarative syntactic sugar.

    We have plans to add state in a later version. Shane Stephens already has a proposal for this written up.

    The naming “Action” is interesting too. It might be more intuitive than what we’re calling an AnimFunc at the moment.

    Also, it seems like this model uses an integral number of milliseconds for duration. Currently we use a real number representing seconds. I wonder if milliseconds are more intuitive since that’s what window.setTimeout uses.

    I’ll add these items to the agenda for our next conference call.

  5. modeless says:

    What I really want in an animation API is the ability to seamlessly switch from one animation to another without stopping or messing up the current state. For example, the door opening and closing animations in the video look fine as long as they never overlap, but if you switch to the closing animation before the opening animation is done it looks terrible.

    What I want is to be able to interrupt the opening animation halfway through by switching to the closing animation, and have the door smoothly transition from opening to closing. Ideally not just the position but also the velocity of the door would continuously transition to the new animation.

    I’ve never seen an animation API that handles this gracefully, even though it’s extremely common in actual applications. With the current CSS animations it’s not even possible to get the current velocity of an animation without reimplementing the calculations in JavaScript yourself.

  6. Brian says:

    Hi modeless,

    Thanks for your comment. I’m pretty sure the feature you described is covered by the MERGE combinator in the current spec. (The link is: https://dvcs.w3.org/hg/FXTF/raw-file/tip/web-anim/index.html#the-merge-combinator but links within a page don’t seem to work in most browsers with respec).

    I think what many applications really need is a notion of state. We have a proposal for that but decided to leave it until version 2. The merge behaviour is something added to support state machines.

    Actually, just recently I was thinking that we should drop merge for now since I thought most applications won’t use it, but after receiving your comment I’m persuaded to leave it for now. So thanks very much for your comment!

    Brian

  7. You left a comment on my blog so I thought I would reciprocate, although on an old post. I swear I am not the commenter named modeless, who described exactly a problem that is solved by an animation usage pattern I use. He even used the word seamlessly. 急に鳥肌を立つ、ね。The solution, of course, is concurrent animations that are defined absolutely but behind the scenes converted to a relative from value of old minus new and to value of zero. It is for workhorse animation, for layout not movies, and the only way to respond to user events. I have been reading about SMIL and web animations but haven’t made any feature requests… yet. http://kxdx.org 皆、見て下さい!

Leave a Reply


css.php