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:

Intersection of features provided by CSS, SVG, and Web Animations

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:

Intersection of features provided by CSS, SVG, and Web Animations

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.