Mozilla Japan

Mozilla Japan engineering is quite hot right now

Fortunately Taipei’s shaved ice extravaganza Ice Monster has popped-up just around the corner from our office in Tokyo!

Now that I’ve sufficiently buried the lede, I’d like to introduce you to what our platform engineers have been up to in the land of the rising (and scorching) sun.

Since April we’ve been trying to focus our efforts around two themes: Input and Animation although we also work on other items like fonts and supporting partner projects. Some of the things we’re tackling this quarter include:




Gecko guts

Makoto takes the floor to teach us the ins and outs of e10s in the first ever Gecko inside event

Last night we held our first “Gecko inside” meetup. The idea is for engineers to teach each other about different parts of our code and provide some useful information to people who are interested in contributing. This time, Makoto gave us a great overview of e10s in Firefox (slides).

We plan to do it again on September 8 including a special guest appearance from Gary Kwong presenting on fuzzing in Firefox!

If you’re in Tokyo please drop by! Better still, if you’re hacking on any of the same things, why not pay us an extended visit? In addition to Taiwanese shaved ice, we’ll gladly introduce you to some tasty sushi or barbecued beef tongue.

Status updates

What do we do with SMIL?

Earlier this week, Blink announced their intention to deprecate SMIL. I thought they were going to replace their native implementation with a Javascript one so this was a surprise to me.

Prompted by this, the SVG WG decided it would be better to split the animation features in SVG2 out into a separate spec. (This was something I started doing a while ago, calling it Animation Elements, but I haven’t had time to follow up on it recently.)

I’ve spent quite a lot of time working on SMIL in Gecko (Firefox) so I’m probably more attached to it than most. I also started work on Web Animations specifically to address Microsoft’s concern that we needed a unified model for animations on the Web and I was under the impression they were finally open to the idea of a Javascript implementation of SMIL in Edge.

I’m not sure what will happen next, but it’s interesting to think about what we would lose without SMIL and what we could do to fix that. Back in 2011 I wrote up a gap analysis of features missing in CSS that exist in SVG animation. One example, is that even with CSS Animations, CSS Transitions, Web Animations and the Motion Path module, we still couldn’t create a font using SVG-in-OpenType where the outlines of the glyphs wiggle. That’s because even though Web Animations lets you animate attributes (and not just CSS properties), that feature is only available via the script API and you can’t run script in some contexts like font glyph documents.

So what would we need? I think some of the following might be interesting specs:

  • Path animation module – We need some means of animating path data such as the ‘d’ attribute on an SVG element. With SMIL this is actually really hard—you need to have exactly the same number and type of segments in order to interpolate between two paths. Tools could help with this but there aren’t any yet.

    It would be neat to be able to interpolate between, say, a <circle> and a <rect>. Once you allow different numbers of segments you probably need a means of annotating anchor points so you can describe how the different paths are supposed to line up.
    (If, while we’re at it, we could define a way of warping paths that would be great for doing cartoons!)

  • Animation group module – SMIL lets you sequence and group animations so they play perfectly together. That’s not easy with CSS at the moment. Web Animations level 2 actually defines grouping and synchronization primitives for this but there’s no proposed CSS syntax for it.

    I think it would be useful if CSS Animations Level 2 added a single level of grouping, something like an animation-group property where all animations with a matching group name were kept in lock-step (with animation-group-reset to create new groups of the same name). A subsequent level could extend that to the more advanced hierarchies of groups described in Web Animations level 2.

  • Property addition – SMIL lets you have independent animations target the same element and add together. For example, you can have a ‘spin’ animation and a ‘swell’ animation defined completely independently and then applied to the same element, and they combine together without conflict. Allowing CSS properties to add together sounds like a big change but you can actually narrow down the problem space in three ways:
    1. Most commonly you’re adding together lists: e.g. transform lists or filter lists. A solution that only lets you add lists together would probably solve a lot of use cases.
    2. Amongst lists, transform lists are the most common. For this the FXTF already resolved to add translate, rotate and scale properties in CSS transforms level 2 so we should be able to address some of those use cases in the near future.
    3. While it would be nice to add properties together in static contexts like below, if it simplifies the solution, we could just limit the issue to animations at first.

.blur {  filter: blur(10px); }
.sepia { filter: sepia(50%); }

There are other things that SMIL lets you do such as change the source URL of an image in response to an arbitrary event like a click without writing any programming code but I think the above cover some of the bigger gaps? What else would we miss?

Status updates

After 10 years

Yesterday marks 10 days to the day since I posted my first patch to Bugzilla. It was a small patch to composite SVG images with their background (and not just have a white background).

Since then I’ve contributed to Firefox as a volunteer, an intern, a contractor, and, as of 3 years ago tomorrow, a Mozilla Japan employee.

It’s still a thrill and privilege to contribute to Firefox. I’m deeply humbled by the giants I work alongside who support me like I was one of their own. In the evening when I’m tired from the day I still often find myself bursting into a spontaneous prayer of thanks that I get to work on this stuff.

So here are 8 reflections from the last 10 years. It should have been 10 but I ran out of steam.

Why I joined

  1. I got involved with Firefox because, as a Web developer, I wanted to make the Web platform better. Firefox was in a position of influence and anyone could join in. It was open technically and culturally. XPCOM took a little getting used to but everyone was very supportive.

What I learned

  1. Don’t worry about the boundaries. When I first started hacking on SVG code I would be afraid to touch any source file outside /content/svg/content/src (now, thankfully, dom/svg!). When I started on the SVG working group I would think, “we can’t possibly change that, that’s another working group’s spec!” But when Cameron McCormack joined Mozilla I was really impressed how he fearlessly fixed things all over the tree. As I’ve become more familiar and confident with Firefox code and Web specs I’ve stopped worrying about artificial boundaries like folders and working groups and more concerned with fixing things properly.
  2. Blessed are the peacemakers. It’s really easy to get into arguments on the Internet that don’t help anyone. I once heard a colleague consider how Jesus’ teaching applies to the Internet. He suggested that sometimes when someone makes a fool of us on the Internet the best thing is just to leave it and look like a fool. I find that hard to do and don’t do it often, but I’m always glad when I do.Earlier this year another colleague impressed me with her very graceful response to Brendan’s appointment to CEO. I thought it was a great example of peace-making.
  3. Nothing is new. I’ve found these words very sobering:

    What has been will be again,
    what has been done will be done again;
    there is nothing new under the sun.
    Is there anything of which one can say,
    “Look! This is something new”?
    It was here already, long ago;
    it was here before our time. (Ecclesiastes 1:9–10)

    It’s so easy to get caught up in some new technology—I got pretty caught up defending SVG Animation (aka SMIL) for a while when I worked on it. Taking a step back though, that new thing has almost invariably been done before in some form, and it will certainly be superseded in my lifetime. In fact, every bit of code I’ve ever written will almost certainly be either rewritten or abandoned altogether within my lifetime.

    In light of that I try to fixate less on each new technology and more on the process: what kind of person was I when I implemented that (now obsolete) feature? What motivated me to work at it each day? That, I believe, is eternal.

How I hope Mozilla will shape up over the next 10 years

  1. I hope we’ll be the most welcoming community on the WebI don’t mean that we’ll give free hugs to new contributors, or that we’ll accept any patch that manages to enter Bugzilla, or we’ll entertain any troublemaker who happens upon #developers. Rather, I hope that anyone who wants to help out finds overwhelming encouragement and enthusiasm and without having to sign up to an ideological agenda first. Something like this interaction.
  2. I hope we’ll stay humbleI’d love to see Mozilla be known as servants of the Web but when things go well there’s always the danger we’ll become arrogant, less welcoming of others’ ideas, and deaf to our critics. I hope we can celebrate our victories while taking a modest view of ourselves. Who knows, maybe our harshest critics will become some of our most valuable contributors.
  3. I hope we’ll talk less, show moreBy building amazing products through the input of thousands of people around the world we can prove Open works, we can prove you don’t need to choose between privacy and convenience. My initial interest in Mozilla was because of its technical excellence and welcoming community. The philosophy came later.
  4. I hope we’ll make less t-shirtsCan we do, I don’t know, a shirt once in a while? Socks even? Pretty much anything else!
Status updates

Animations on Fire @ Graphical Web 2014

Just recently I had the chance to talk about authoring animations of CSS/SVG for better performance at The Graphical Web 2014. I thought I’d put up the slides here in case they’re useful to others.

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:
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

Players wanted: the pause and seek game

Last time I introduced timing groups in Web Animations as a simple yet powerful tool for synchronising animations. Great as they are, the open up a few interesting questions. For example, what happens when you pause an animation that’s in a timing group?

Consider the following parallel timing group. It has two child animations, A and B, and the group repeats twice.

A parallel timing group with two children A and B whereby the group repeats twice

Suppose we pause child animation A at the red down arrow and then resume it at the red up arrow. What should happen?

One option is to just let everything play as normal.

A child of the parallel timing group is paused such that all other animations continue to play as normal

But then what happens to the second run of A? Does it run at all? Get squashed? Get overlapped? And if so, who wins?

So what if we automatically unpause animation A when we hit an iteration boundary?

A child of the parallel timing group is paused such that it is automatically unpaused when an interval boundary is reached

From an API point-of-view that automatic unpausing is tricky and likely to lead to bugs where a piece of script assumes an animation is paused but on some devices the interval boundary occurs before the script gets a chance to run, breaking the assumption.

Another approach is just to stretch the iteration to fit the pause like so.

A child of the parallel timing group is paused such that the iteration is stretched to fill the pause amount

This mostly works for parallel containers but, like the other behaviours, it doesn’t make sense for a sequence timing group because the sequence is broken.

Also, all these behaviours are problematic if we seek the group whilst a child is paused. And if we seek backwards after unpausing what is the expected state of the world?

The approach that provides the most intuitive behaviour in these situations is simply to pause the group as a whole like so.

A child of the parallel timing group is paused by applying the pause to the group

This of course applies all the way up the tree.

But what do other APIs do?

Looking at a number of other animation APIs:

  • QML just ignores play control on animations if they’re in a group.
  • Android doesn’t include repeating etc. on groups and animations and groups don’t have play control.
  • In WPF only the root clock can be interactively controlled.
  • In HTML, media slaved to a controller (similar in some sense to a timing group) behaves differently to independent media. You can pause it independently, but seeking throws an exception. Pausing due to buffering pauses the controller. There is no repeating.

In summary, QML and WPF push pausing to the root of timing hierarchy. Android and HTML manage to do something different but only because they don’t allow groups to repeat.

For Web Animations, like QML and WPF, the best option is to push pausing and other play control to the root of the timing hierarchy. The trouble comes when we try to represent this in the API.

At first we tried to do this transparently, that is, you’d call pause and it would just go up to the top-level timing group and apply the pause there. However, a couple of concerns were raised with this,

  • It’s not obvious that the operation you’re performing may have wide-reaching effects.
  • It doesn’t work for seeking since the time values are relative to the child not the parent. HTML just throws an exception in this case, but some people felt uncomfortable that this method would sometimes work and sometimes throw an exception depending on whether there was a parent timing group or not.

Enter the players

In order to emphasise the fact that play control (pausing, seeking, etc.) takes place at the root-most timing group a new concept, the player, was introduced. A player plays things. It’s the point of attachment between some timed content and a timeline. The arrangement is as follows.

Players form the point of attachment between the rootmost timing groups and animations and a timeline.

From a code point of view it looks like this:

  var anim = elem.animate({ left: '20px' }, 3);

This separation hopefully makes it more obvious to an author that the change they are making may have more wide-reaching effects.

It also can make avoiding some common coding mistakes a little easier.

  // The following could cause some animations to be sped up 4, 8 times or more
  elem.getCurrentAnimations().forEach(function (anim) {
    anim.player.playbackRate *= 2;
  // The following will speed everything up by a factor of 2 and no more
  elem.getCurrentPlayers().forEach(function (player) {
    player.playbackRate *= 2;

It also has a few nice properties:

  • TimedItem.localTime is always readonly and has a different name to the always writeable Player.currentTime.
  • TimedItem.timing.playbackRate affects the model in the same way as changing other timing parameters does including possibly causing the playback position to jump. Player.playbackRate, on the other hand, makes dynamic changes so that the current playback position is preserved.

Unfortunately, introducing the idea of players adds conceptual weight to the API. It’s probably one of the most unfamiliar concepts for people coming to the specification (hence this blog post!). For these reasons I resisted this change strongly but ultimately lost. :)

That said, it does make the model more consistent and therefore, to some degree, more intuitive. It is also expected that many authors will never use this functionality (jQuery, for example, does not provide pause control) and so this additional concept shouldn’t become a barrier to adoption for simple usage.

I’ll look forward to seeing how authors take to this concept. If you have any feedback, feel free to follow-up at with subject [web-animations].

Upcoming changes

Recently we’ve been discussing some changes to the way players work. Currently they just keep playing forever but we think it might make sense for them to behave more like a VCR and stop when they hit the end of their media. This would allow us to define a reverse() method that behaves sensibly and perhaps make players then-able.

You can see some of the discussion in the minutes from our recent telcon, item 6, Making players stop. As always, your comments are welcome at

Status updates

Group and conquer: timing groups for your synchronization woes

Once you start animating anything more than simple fade and slide effects, pretty soon you start wanting to synchronize things. The penguins should start dancing together, the watermelon should explode the moment the blind-folded person hits it, the credits should roll after the movie finishes and so on.

In this post I want to outline the approach taken to these problems in Web Animations and the biggest new feature in the spec: timing groups. But first, what can we already do?

Synchronization in CSS

In CSS you can do a few things:

  • By toggling a style on a common ancestor you can get two animations to start at the same time. For example, see this example from Smashing Magazine.
  • Using animation-delay you can stagger the start times of animations and by calculating the length of A, you can use this to make B start after A.

There are a few limitations though:

  • It’s not particularly scalable—if A changes duration, you need to update B as well. That’s particularly problematic if, for example, A is a video of unknown length.
  • You’re not declaring the temporal relationships between different animations—their synchronization is just a by-product of how you triggered them—and as a result there’s no easy way to pause or seek a particular set of animations.
  • It requires you to structure your document so that you’ve got a common ancestor to toggle a class on. Suddenly your document structure is doing triple duty: semantics, layout (all those empty <div>s to persuade CSS to do what you want), and timing.
  • You can’t create animations on the fly that line up with already running animations.

The problem with SVG and syncbase timing

SVG has a neat feature which seems to meet these needs: syncbase timing. That lets you create arrangements like:

<animate id="a" begin="b.end" ... />
<animate id="b" begin="0s" end="c.end" ... />
<animate id="c" begin="a.begin+2s" ... />

That would seem to do everything we could ever want, except it has a few problems:

  • It’s complex. The above example is just the tip of the iceberg. You can have any number of conditions on both the begin and end of an animation pointing to any other animation including the same animation. You can create cyclic dependencies and some are allowed, some are not, and the rules for breaking cycles are vague (and thus, inconsistently implemented).

    What’s more, all this feeds in to the most complex part of SVG animation: deciding what intervals to create. As a result if you want to determine what animations are active at a given time, you have to step through all the significant moments up to that time and work out what intervals to create. This makes seeking costly.

  • Another problem is that you can’t cancel just part of such a sequence.

    For example, imagine you have a sequence of actions A, B, and C representing “fade the background of the button from grey to blue”, “pulse it”, then “make it glow”. You trigger A when the mouse moves over the button but the mouse suddenly leaves while A is still running. You cancel A (e.g. using end="mouseout" or endElement) but then B still runs since it sees that A has ended. And consequently C also runs. There’s no way to cancel the chain and nor is there any way to seek/pause such a chain independently of other animations that might be running.

Enter timing groups

These use cases can be addressed using the concept of timing groups. This is a well-established concept in animation APIs. For example,

  • QML has ParallelAnimations and SequenceAnimations.
  • SMIL has <par>, <seq>, and <excl> time containers.
  • Android has AnimatorSets that play animations together or in sequence.

Common to all these APIs is the concept of two types of groups: groups that run animations together and groups that run animations in sequence.

Furthermore, in each of these APIs the two types of groups can be nested so you can easily build complex arrangements up from simple parts in a way that is easy to reason about.

For example, the following arrangement:

<animate id="curtainOpens" ... />
<animate id="penguinADances" begin="curtainOpens.end" ... />
<animate id="penguinBDances" begin="curtainOpens.end" ... />
<animate id="curtainCloses" begin="penguinBDances.end" ... />

could be represented with timing groups as:

  <animate id="curtainOpens" ... />
    <animate id="penguinADances" ... />
    <animate id="penguinBDances" ... />
  <animate id="curtainCloses" ... />

Graphically, the arrangement is as follows:

A sequence timing group that contains a parallel timing group as a child. The parallel timing group waits for the previous child of the sequence timing group to finish, and then the children of the parallel timing group play simultaneously. After they have finished the next child of the sequence timing group plays.

You can cancel a chain of animations in this case by simply cancelling the group. The hierarchical nature of the groups also means seeking is constant-time with regards to the seek interval.

Timing groups in Web Animations

In Web Animations we have adopted this same approach of using timing groups with the following features:

  • Two types of timing groups: parallel, sequence.
  • Children of a group can have a delay which can also be negative. This allows children of a sequence group to overlap so you can, for example, start a fade animation 2s before a video ends. (SMIL does not allow negative delays on children of a sequence group.)
  • Any timing property you can apply to an animation, you can also apply to a group which means you can repeat, ease, reverse, delay, or speed up a group.

The last point is interesting since most other APIs don’t do that. It can be quite useful as we showed in a demo of this in our preview video last October where we combined a door closing animation and a creaking sound “animation” in a group then eased the group.

However, it introduces some complexity. For example, since easing functions can be non-invertible, it means you can’t always convert from child time to group time which complicates event handling.

Also, the interaction between fill modes specified on a group and on a child are not always obvious and we need to revise the spec to be more intuitive in this area.

Building up the example above using the API in Web Animations look like the following.
  new SeqGroup([
    new Animation(...),   // Curtains open
    new ParGroup([
      new Animation(...), // Penguin A
      new Animation(...)  // Penguin B
    new Animation(...)    // Curtains close

On a side-note, we’ve had some feedback about ParGroup and SeqGroup being a bit cryptic, especially for anyone not familiar with SMIL (which is pretty much everyone). ParallelGroup would be more readable but it’s a lot to type for something we expect authors to use a lot. I wonder if just Parallel would make sense? Perhaps this could be a named constructor for ParallelGroup? If you have any suggestions we’d love to hear them. Either respond here, or, better yet, send a mail to with subject [web-animations].

The mapping of timing groups to SVG and CSS has yet to be worked out.

Future extensions to timing groups

One common request that arises in regards to timing groups is the ability to set the duration of the group and specify the duration of the children as fractions of that parent. That sort of adaptive duration is something that’s quite useful but also can easily become complex—like CSS flexbox in the temporal domain. It’s something we’ll look at in a future version but for now we’re comfortable it can be added to the model and API fairly naturally.

If you want to read up on the detail, have a look at the spec. As always, your comments are welcome at with subject [web-animations].