Web animation in 2017

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.

Specs:

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!