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.

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 (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!

Advertisements
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.

gecko-inside

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!

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!

pseudo

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

sakura-2

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:

Input:

Animation:

Other:

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: