Status updates, Web Animations

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.


  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 (introduction), 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!

Status updates, Web Animations

MozAnime in 2016

MozAnime is the informal name we use to cover all the work on animation-related features at Mozilla. We’re based in Tokyo, Tochigi, Taipei, Toronto, and… somewhere in France that probably, hopefully, starts with a ‘t’ as well.

I can’t wait to tell you all the things I’m looking forward to next year, but in this post I want to share some of the highlights from the MozAnime crew in 2016.

Shipped Element.animate

Five years since I first proposed Web Animations we finally shipped some of it! We worked together with the Chrome team to make sure we have an interoperable feature set (something web-platform-tests helped with a lot!) and thanks to their work on a polyfill, authors can now write cross-browser animations that in many cases will run in a separate thread. See the hacks article for more details.

Performance of regular JavaScript animation vs Element.animate()

Finished* Web Animations

Of course, Element.animate is only the tip of the iceberg. Web Animations has a lot more to offer such as being able to modify and query animations—even CSS-defined animations—on the fly and make independent animations that morph together. We finally landed the last pieces of that API last weekend.

Progress of Web Animations implementation status throughout 2016

*Technically, however, it’s not actually finished. We haven’t done SharedKeyframeList because that part of the spec is likely to change. In fact, there are a few parts of the spec that will change so we’ll need to do a bit more work on those before we’re ready to ship. More on that next time. Nevertheless, it’s a significant milestone and as far as I can tell we’re the first browser to get there although Chrome is coming along too.

Improved Animation DevTools

We launched our first animation DevTools in 2015 but this year we deepened the collaboration between platform work and DevTools producing some new features like:

Animations on pseudo-elements

Animation inspector showing a throb animaion running on the pseudo element

Platform performance information

DevTools showing an explanation for why animation of the transform property could not be optimized.

This was initially implemented by an intern who did a great job. This is incredibly useful—if you’re debugging animation performance please give it a try! You can find more details on MDN.

Richer timing display

DevTools showing different easing effects applied to two animations

This is just the start of making the animation inspector much more useful. See Patrick’s hacks article for all the details of this first step. Because of the close integration of platform and DevTools work, these tools also handle the obscure edge cases that might not be apparent to a casual user of animation features (like large negative end delays that overlap start delays). There is a lot more work to do here but the next piece is already up for review and there is more on the way.

(And just in case you’re wondering what an excessively large end delay looks like, it’s something like this.)

DevTools when viewing an animation with a negative end delay larger than its active duration

Proposed scroll-linked animations and started implementation

At W3C TPAC this year we proposed a spec for scroll-linked animations based on a previous proposal by Apple. There was strong support for pursuing this and Google have been actively involved too, giving great feedback. We have an initial implementation due to land any day now but it will be preffed-off initially since there is still a lot of spec discussion that needs to happen.

Specced and implemented new transition events

Our experience with Firefox OS helped us realize how difficult it can be to work with transitions. Sometimes they don’t fire (e.g. you set a property to its existing value), and sometimes they get cancelled (e.g. you “re-rendered” a part of the DOM and blew away the elements that were transitioning), so if you’re waiting for transitionend you could be waiting a long time.

So we specced transitionrun (for when the transition is created), transitionstart (for when the transition finishes its delay—mostly since Edge already had this), and transitioncancel (for when the transition is dropped without reaching the end).  They’re implemented in the latest Nightly edition of Firefox (53) and we’ll implement a similar animationcancel event for CSS animations soon.

What’s coming up in 2017?

That’s enough for one post but I’ll follow up early in the new year with what we hope to do in Mozilla-land in 2017 as well as some of the other animation-related developments I’m looking forward to in the wider Web landscape.

Thank you to the many people who contributed, not only to Mozilla but also to many fantastic people at Google and Microsoft in particular whom I had the pleasure of working with this year. Happy new year!

Mozilla Japan, Status updates, Web Animations

Gecko insiders

At Mozilla Japan, we’ve been doing a series of monthly events called “Gecko inside” where we discuss details of hacking on Gecko in the hope of helping each other learn and helping new contributors to get started.

Last weekend we held a special “write a patch” day where we gathered a group of long-time contributors to mentor first-time contributors through the process of setting up a build environment, writing a patch, and getting it reviewed and landed.


We fixed nearly a dozen bugs on the day and if you were hanging around on #developers about that time, you might have been surprised at the stream of Japanese names ticking by.

lots of Japanese commits

It was a fun event with veterans and first-time contributors alike asking if we could do it again.

Gecko internals

In keeping with the topic of new contributors, we were recently very pleased to have Ryo Motozawa join us for an internship during his university’s winter break. Ryo came to us with more curiosity than experience but quickly found his way around implementing WebIDL interfaces, animation timing features, and a number of DevTools features including exposing detailed animation performance information (due to land any day now!) using an interface Hiro recently built—all in just 2 months! Nice work Ryo!


(And, before you mention it, there’s already a bug to fix the text in that tooltip!)

Gecko geeks

Some of the other notable things we’ve been plugging away at here in Japan include:

Also, while far from a Japan-only effort, another animation-related feature I should mention is that thanks to platform work from Boris Chiou and Daisuke Akatsuka, and DevTools work from Patrick Brosset, the animation inspector now finally works with animations on pseudo-elements!


They’re just a few of the things we’re excited about at the moment. Oh, and this view!


Status updates, Web Animations

Web Animations @ html5j 2013

Over the weekend I had the chance to speak about Web Animations at the HTML5 conference 2013 in Tokyo. I put a fair bit of work into the presentation so I thought I’d put up an English version of the slides (including videos of the demos) in case they’re useful to someone else looking for a gentle introduction to Web Animations.

I ran out of steam when producing the last few slides so it kind of ends with a fizzle but I put a fair bit of work into the other ones so hopefully it’s entertaining. Although you can’t tell from the slideshare version most of the slides include animation somewhere and most of the pictures are made with SVG so I think it looked pretty.

View the presentation slides

In the rare chance that you’re reading this blog directly or the syndicator didn’t eat this bit, you can view the slides right here:

(If you’re curious there’s the HTML version too. But be warned that it doesn’t have explanatory notes like the slideshare version; it won’t work in Chrome since it makes heavy use of scoped styles; and one animation relies on enabling mixed-blend-mode which is only in Aurora or Nightly, see bug 902525.)

(日本語の資料ももちろんあります!イベントの配信、 分かりやすくしたスライド, 原本のHTML版のスライドをご覧ください。)

Status updates, Web Animations

Introducing Web Animations

Today we finally shipped the First Public Working Draft of Web Animations!

Over the coming weeks I’d like to introduce some of the key concepts as well as some of the issues that need your input.

First, I’d like to give an overview of where the spec comes from and what it covers.

Why Web Animations? A summary of happenings until now

On the Web today we have CSS Animation (including Transitions) and SVG Animation and they both have their problems. For example, CSS is so simple it doesn’t even support synchronization and SVG is pretty hairy when it comes to interval negotiation and syncbase timing—and it’s SVG-only. Most of all though, they’re completely separate.

Also, Microsoft don’t support SVG Animation. They have consistently maintained that they want to see a single model for animation on the Web (e.g. minutes) and that that model should have an API. That’s a very reasonable position in my mind, albeit frustrating for authors who want to use SVG Animation now.

The story since then is as follows:

What’s in the box?

Basically, this:


Web Animations is essentially a common model for animation that underlies CSS and SVG. It covers the common features of both plus a few only found in one or the other.

It also has a few extra features not currently found in either:

Timing groups
This is the primary means of synchronization.
It’s quite powerful but I’ll leave the details and justification for this to a separate post.
Speed control (#1 and #2)
This is a requested feature for SVG2 and may be useful for achieving reversing effects such as exposed in CSS.
Custom effects (API)
This allows the Web Animations timing model to be used to drive animations of HTML canvas etc. by registering a script callback.
Iteration start
This is a minor but much requested feature that allows you to start an animation part-way through its interval.

What’s not included?

Bear in mind that Web Animations is essentially a model. It’s not a declarative syntax. That’s something left to other specs. The API happens to be bundled with the model simply because that makes it easy to keep the two in sync.

The arrangement is as follows:


The CSS-specific features required for CSS animations and transitions will be covered in a separate specification, possibly called “CSS Animations/Transitions level 4” which expresses its features in terms of the Web Animations model.

Likewise, current SVG features such as syncbase timing, or targetting attributes (not just CSS properties) will be covered by a separate specification (my next task) expressed in terms of that model. That specification may be called something like “SVG Animation” but I suspect not since quite a few people have expressed interest in allowing it to apply to HTML content too.

Other features that are not included:

  • Bounce/spring timing functions – we really wanted to make this possible and have a couple of simple extensions to timing functions to allow this but we haven’t yet reached agreement about which one is best so we’re leaving them both out for now.
    The plan is to follow up with a separate specification which provides additional timing functions anyway.
    (In fact, with the current working draft, you can’t even do more than one timing function over an animation currently but that will be fixed in the next draft when we introduce chained timing functions).
  • Media integration – this is something a lot of people have been asking for but we decided to postpone it in the interests of progressing the spec along.
    The good news is this used to be part of the spec so we know it integrates very cleanly.
    For now we’ll work on it in a separate spec and if that comes along quickly enough we might merge it back in.
  • State machines – this is something that is very useful when you start programming UI interactions but something we decided is not critical for the first version of the spec.
    Again, we’ll probably work on this as a separate spec.


Originally I opposed the idea of adding an API because I think declarative solutions are generally preferable. However, the API is useful in a few cases:

  • It lets you inspect the state of all animations in the document. Anyone can build developer tools that present you with a timeline of all the running CSS animations/transitions/SVG animations in the document for debugging.
  • It lets you make runtime changes to declarative animations—for many apps a combination of declarative and procedural approaches is the best fit and lets you achieve effects that might not be possible using purely declarative features.
  • For some problems a procedural approach is suitable and in those cases using the API is both simpler than writing the animation loop yourself and also means the browser can optimise the animation for smoother performance and less battery consumption.


Work has started on implementation in Blink and is on the radar for Gecko. Until then a polyfill is coming along in leaps and bounds and covers nearly all of the FPWD.

That’s it for now. I’ll follow up with posts explaining specific features and issues needing input but if you have any feedback on the spec, don’t hesitate to send it along to with subject [web-animations]. Thanks!

Status updates, Web Animations

Help with math(s)

UPDATE: I originally prepared this post before others working on the Web Animations spec assured me they would find a solution. I posted it password-protected for their sake not realising it would show up on planet! Sorry! Anyway, here is the original post for those who were curious. There are already some folks working on this, but other input may still be useful!

One of the limitations of CSS and SVG animations is that you can’t do a bouncing effect. That is, you can’t easily do this:

Bouncing in SVG. Click the circle to restart.
(If the image fails to show, try this link:

You can emulate it (as above), but it really should be the job of the timing function to do this kind of easing.

In Web Animations we’ve been trying to address this. At first I tried creating a simple smoothing function where you’d specify a series of points and it interpolates smoothly between then. This proved more complex than expected so I narrowed the problem down to just spring-like animations.

It’s easy to generate a spring-like function—I found a sine wave plus exponential dampening plus some scaling of the period does ok, but in terms of parameterisation I think you probably want the following handles:

How far past the target value to reach on the first cycle of the spring-like motion. 1.5 means overshoot by 50% (when exposed to CSS and SVG, this parameter might be exposed as just ‘50%’ instead of 1.5). This is particularly useful if, for example, you’re animating something inside a container and want to be sure the effect won’t fall outside the bounds of the container.
How much should it bounce back and forwards before converging on the target value? Higher numbers mean more bouncing. After discussing with the others working on Web Animations spec, this may or may not be the most suitable parameter. If at all possible however we want to reduce the number of parameters to avoid being as complex as QML.

Parameterising the spring function in those terms proved a bit beyond my mathematical abilities. I made the following prototype but it’s all kinds of clumsy.

If the iframe above doesn’t appear, try this link:
Note that it won’t work in Internet Explorer since IE doesn’t support SVG animation.


  • Doesn’t work in all ranges. For example, for an overshoot of 5, the second peak is higher than the first. An overshoot of 1 also doesn’t work.
  • The first part of the curve (on the initial path to the overshoot value) seems wrong—sometimes there are lumps or kinks in it.

Rough requirements for the function, f(x):

  • overshoot is a value in the range [1,∞)
  • elasticity — not even sure if this is the right parameter. It would probably be ideal if elasticity of 1 simply made the animation go to the overshoot value and then return to 1 without any bouncing. A value of 2 might make it overshoot once, dip below 1, then return on 1.
  • For 0 ≤ x ≤ 1 the global(?) maximum of the function is overshoot and this should also be the first maximum in the range
  • f(0) = 0 and f(1) = 1
  • When elasticity is high or overshoot is high it should probably reach the overshoot value sooner since the bounce component will take longer to complete
  • The function should probably not go negative initially, unless overshoot > 2 in which case it might be ok.
  • Not sure if the first part should be ease-in.

As I said, there are already some folks working on this, but if you want to have a try you can fork the fiddle above and hack away. Alternatively, there is an Excel spreadsheet or OpenDocument spreadsheet version.

On the other hand, if you think this is not the most useful function or something more general is possible, feel free to suggest that too!

Status updates, Web Animations

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:

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

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.