Web animation in 2017

Archive Web Animations

Happy new year! As promised I thought I’d share a few of the Web animation things I’m looking forward to in 2017. I’m terrible at predicting the future (I used to be a believer in BeOS and VRML) so this is mostly based on what is already in motion.


  1. CSS transitions – this should move to CR status soon. Part of that involves splitting off a separate Timing Functions spec. That separate spec would give us:

    • Level 1: An additional frames() timing function to do what step-end and step-start should have done in the first place.

    • Level 2: Low-level syntax for export of complex timing functions (multi-segment béziers?), spring timing functions, script-defined timing functions, and perhaps even timing functions that affect the duration of animations.

  2. CSS animations – this too should move to CR soon. All that is really missing is some clarification about the liveness of values and some text about how @keyframes rules cascade. Then we can start work on new things in level 2 like animation-composition.

  3. Web animations – this too is approaching CR and I hope we can ship (most of) the remainder of the API in the first half of this year in Firefox and Chrome. For that we still need to:

    • Add a FillAnimation concept to allow browsers to compact finished but filling animations so they don’t keep consuming memory. This is a bit hard, but seems do-able.
    • Simplify the timing interfaces to use fewer live objects and make the interface consistent with keyframe interfaces. I hope this will simplify the implementation for Edge and Safari too.
    • Add compositeBefore and compositeAfter methods to control how animations combine and overlap.
    • Replace SharedKeyframeList with StylePropertyMaps from Houdini.
    • Integrate a few tweaks to making specifying keyframes more flexible.

    I’m looking forward to shipping additive animation soon since it helps with a lot of use cases, but it really needs FillAnimation first.

    getAnimations is also exciting—being able to inspect and manipulate CSS animations and transitions from the same API—but probably won’t ship until the second half of the year when we have the mapping between CSS and Web Animations clearly specified.

    Being able to ship the finished and ready promise would be great but was blocked on cancelable promises being realized and now it’s not clear what will happen there.

  4. Scroll-driven animations – This is going to take quite a bit of work to get right, but hopefully within this year we can start shipping parts of it so you can create hidey bars and parallax effects that run smoothly on the compositor.

  5. AnimationWorklet – This is also going to take time to make sure it plays well with the other animation pieces in the platform but fortunately the Chrome folks pushing it have been very responsive to feedback and admirable in their willingness to rethink ideas.

At Mozilla, apart from editing and implementing the above specs, some of the bigger animation items I anticipate this year include:

  1. Making our current animation features work with Quantum CSS, i.e. Servo’s style engine. This involves a lot of tricky plumbing but it means Firefox gets faster and Servo gets more spec compliant.

  2. CSS offset (aka CSS motion). We’ve been putting this off for a while as the spec stabilizes but I hope this year we will actually do it.

  3. Promoting various SVG attributes to properties. Tackling this and the previous item would significantly narrow the gap between CSS and SVG’s (SMIL) animation features and let us simplify the SMIL code a lot.

  4. Animation of CSS custom properties. There are patches written but they need some work before they land.

  5. DevTools. We have plenty of ideas here but most of all we want to make our animation DevTools the place to go not just to debug all the above features, but also to author for them!

If any of those items sound interesting to you, please get involved!



I don’t use Github, but I’d like to report an issue with Rikaichamp version 0.0.13. The keyboard shortcut to toggle Rikaichamp on/off (Alt +R) Conflicts with Swedish version of FireFox. The “Edit” menu are viewed instead.


Thanks for the report! And well done in finding me here! You can also ping me on twitter (@brianskold) if that helps.

I’ve filed the following GitHub issue for this: https://github.com/birchill/10ten-ja-reader/issues/30


Thank you for replying and looking into it. :) Keep up the good work.


Alt + R works now. FireFox 58.0.2 (64-bit), Rikaichamp 0.0.13.


Problem is back with FireFox version 59.0.1.


Ok, thanks for the report. I’ll make sure this stay on my list of things to fix.


Hello, Brian! Thank you for the fantastic plugin Rikaichamp! We wouldn’t translate japanese visual novels without it! I want to make a donation to express my gratitude.) Do you have a Paypal account?


Thanks Nazon1! Wow, that’s very generous of you!
I’ve never received money on PayPal before but you can try to send it to birtles+japan@gmail.com.


Hi again – this should finally be fixed in the latest version of Rikaichamp 0.0.24 which lets you customize the shortcut key used to enable Rikaichamp. I’m sorry about the delay!


Sorry to contact you here but this is the website you left on firefox. firefox suddenly disabled rikaichamp because “it could not be verified for use in firefox”. Is there anything you can do? It saves so much time.


I’m afraid it’s not just rikaichamp. Currently all add-ons on Firefox are broken. The add-ons team are working on it right now and testing a fix. Hopefully it will be resolved soon. Sorry for the inconvenience.

Leave a reply

Most markdown like **bold** and _italic_ is supported.

Never shown. Only used for looking up your gravatar.