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:

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:

overshoot

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.

elasticity

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.

Problems:

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

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:

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.

Personally, I was involved in running the Parapara Animation Workshop* where kids enjoyed drawing simple frame-based animation on a tablet which was then added to a much bigger animation projected on the walls. The purpose of the project was to teach kids the basics of animation as well as to encourage them to be not just web spectators but web makers.

It’s a workshop that was originally done by a group of Keio University Students and they helped run it again this time. The main difference is that last time it was mostly iOS-based, this time it was all Web.

Christian Heilmann has written up a great summary of this part of the program including a quick interview where you can see how it worked.

Japanese kids are really creative so it was a really fun time. But not only was the event fun, the technology side was really fun too.

Some of the technology used

• SVG—heaps of SVG. The hand-drawn paths, UI widgets, all of the animation, all of it is SVG. In particular we used a lot of SVG Animation and even SVG applied to HTML to provide the glowing effect on the form text (as per the designer’s prototype—not my idea!)
• Fennec (Firefox for Mobile)—Just a regular release build (version 9), plus Matt Brubeck’s Full Screen add-on and a few config tweaks.
• Touch events
• CSS calc
• CSS Transitions

What went well

• SVG’s native motion on a path (<animateMotion>) saved us so much time. The auto-rotate feature (rotate="auto"), path APIs (getPointAtLength), and ability to calibrate the path length (pathLength="1") also made it easy to position animations at just the right place so they would appear on the screen as soon as the user pressed “send”.
• Using SVG made it really easy to do the drop shadows. Just a transform and a blur filter and we were done.

  

• SVG animation was surprisingly fast. I expected it to be really slow but it was the fastest of the alternatives we tried. That said there’s still a lot more work to be done (see below).
• Overall SVG just proved really versatile. Being able to show a faint greyed outline of previous frames just by setting an attribute was great. Likewise being able to do all the animation work on the client-side and then just serialise the subtree and send it to the server was so much simpler than the previous version.
• Deployment over the Web was great. Just refresh the page to pick up the bug fixes! Likewise when we ran out of tablets at one point we could just load up the editor URL on a laptop and keep drawing.

What didn’t go so well

• The app marketplace. We badly wanted to package it all up as a Web app using the framework developed by the Mozilla Labs Apps project. We hoped that would give us full-screen display and stop the user from accidentally navigating to other pages. We had high hopes but were shattered to find the Android runtime launched the app in a Webkit runtime which didn’t even support SVG.
• Going full-screen. Due to some technical reasons we were stuck with an old version of Fennec and old UI which took some coaxing to go full-screen and stop the chrome from flying in when the user was drawing. Fortunately the bugs that stopped us from using a more recent version of Fennec appear to have been fixed so next time we can hopefully use the Fullscreen API and multi-touch for drawing with all your fingers at once (something the really young kids really wanted to do!)
• CSS and UI layout. Countless hours were sunk into trying to convince CSS to layout widgets on the screen. In the end I gave up and did half of it in script. I’m told CSS flexbox can help a lot here but I spoke to one implementer of flexbox who said that some of the things we were trying to do weren’t possible even with flexbox.
• Graphics performance. For the combined animation we badly need a boost to our SVG rendering performance. On Windows the performance was generally ok (if you don’t have a loud fan!) but occasionally got jittery. On Mac it looked terrible. We still have a way to go here. Apart from the graphics performance there’s still lots of room to optimize SVG animation itself too. For the editor running on the tablets, I have one patch awaiting review which I hope will make using SVG’s path APIs faster and speed up the drawing and erasing operations.

The result

The gallery of animations:

http://parapara.mozlabs.jp/MozillaVision2012/

The editor:

http://parapara.mozlabs.jp/MozillaVision2012/editor/

And, of course, the code is waiting for your help at github!

Feedback

“That’s a web page?!?” I’m certain that most people who used the demo were oblivious to the fact they were using the Web and that’s probably the greatest success of this demo. Without exception, everyone who asked about the technology was surprised it was Web-based. Everyone assumed it was a native Android app or otherwise Flash.

“That’s SVG?!?” The web developers who came were also surprised at the use of SVG. Most had never really thought of making use of it. They assumed we were using canvas.

“I want to cry, this is the first time I’ve seen Fennec used for something other than reading the news”

Although a lot of the features we used are still in development it was very rewarding to see how much is already possible with Open Web technologies. We’ve had many requests to run this workshop elsewhere and, with your help, it will hopefully get better each time. Thanks very much to the Parapara Animation team and to everyone who contributed to Fennec, Gecko and the Web standards that this is built on.

* For anyone wondering what “parapara” means, it’s the sound of flipping paper and its use here comes from “parapara manga” which means “flipbook comic”. It’s also the name of a kind of hand dancing so we might have to reconsider the name so as not to disappoint the kids.

There’s CSS transitions for all sorts of animated eye-candy, major JS speed-ups to give scripted animations a boost and mozRequestAnimationFrame to get keep them smooth and in sync, and a whole host of other graphics and video improvements. Oh, and SMIL in SVG!

Speaking of which, I thought I’d bring you up to speed on some of the recent progress on the SMIL front.

Event timing

One of the more recent additions to our implementation is the ability to key animations off DOM events such as mouse clicks and key presses.

This paves the way to creating widgets of questionable aesthetic value:

(View demo. You’ll need to be running a recent nightly to experience this button is all its tacky glory. With the latest Firefox 4 beta the motion will be jerky due to bug 557885.)

However, SMIL animations need not only be keyed off SVG events but any event in the current document is fair game. So, for example, suppose we want to add a tape animation that runs whenever a certain video is in play, we can do it with this piece of SMIL:

(View demo)

In addition to events, you can also key animations off:

• key presses: <animate begin="accessKey(a)+1s"…
• other animations: <animate begin="otherAnimation.begin-2.5s"… (and this is generally a much better choice than event timing when you want to keep animations in sync. Although you can write begin="otherAnimation.beginEvent" you may get surprising results when a seek is performed. Use begin="otherAnimation.begin" instead.)
• repeat iterations: <animate begin="otherAnimation.repeat(2)+25ms"…
• plain old time offsets: <animate begin="12.3h"…
• all of the above! <animate begin="rect.click; accessKey(a)+1s; otherAnimation.begin-2.5s; otherAnimation.repeat(2)+25ms; 12.3s"…

SMIL and script are friends

There are a lot of advantages to using SMIL over script (it’s generally easier for a start!) but sometimes it can’t do everything you need. In those cases you can use both together!

SMIL → Script: To synchronise script with SMIL, just listen for the relevant time events generated when animations start (beginEvent), repeat (repeatEvent), and stop (endEvent). If you need a bit more context you can always query the animation’s start time and current time too.

Script → SMIL: To go the other direction, that is, to kick-start SMIL from script, just use the appropriate time control interfaces beginElement, endElement on the target animation, or seek and pause all animations in the <svg> block as a whole with setCurrentTime, pauseAnimations and friends.

SMIL outside the box

While we’re only supporting SMIL for SVG content that doesn’t mean it’s entirely off limits to your HTML content. Not only can we tie SMIL to HTML events as above but we can also apply various SVG features to HTML, and these places can play host to a bit of declarative animation too.

(View demo)

What’s left?

Still, there are a few features missing in our SMIL implementation that are yet to come. I’m maintaining a somewhat detailed summary, but in short we’re missing:

• Mexican waves — There are still a few SVG data types that can’t be animated yet. Paths are very much on the way, but lists of points are yet to come. That means all your squiggling, warping, barrelling, twisting, waving lines and stars will have to wait a little longer to mesmerise the world. Hopefully most of this will be done in time for Firefox 4.
• Hyperlinking — The ability to trigger animations from a hyperlink is also yet to come but will probably not make it’s debut until after Firefox 4.0.

What’s not on the radar?

There are also a couple of features that are neither done, nor likely to get done in the foreseeable future. These are:

• <animateColor> — So long as <animate> honours color-interpolation then <animateColor> isn’t necessary and only complicates the Web. See bug 436296. We recommend using <animate> instead. (This issue was recently discussed on www-svg.)
• Wallclock timing — That is, the ability to set up an animation to begin at 2011-01-01T00:00:00+09:00. Real uses cases for wallclock timing were discussed on www-smil earlier in the year but it seems the syntax provided by SMIL, at least as far as it is used in SVG, is insufficient for these use cases. For the time being, we’d rather not clutter the Web platform by implementing something half-baked. For most use cases, it should be possible to provide this sort of functionality by adding a sprinkling of script to your SMIL.

UPDATE: I just noticed Robert Longson (who’s played a big part in us getting to this point) beat me to reporting much of this news, so for more details on where we’re up to see his post too.

I thought I’d just take this chance to acknowledge some of the people who’ve helped get us here. Particularly Daniel Holbert for his incredible helpfulness and for just being awesome at everything he does; Jonathan Watt for all his help with SMIL recently and for always looking out for me; Robert O’Callahan for his oversight, invaluable input, and support technical and personal; and Chris Double for keeping SMIL moving in the early days.

Also, as alumni of the University of Technology, Sydney (UTS) I used their library a number of times last year as a kind of virtual office. It’s a great library where they really try to help the students, allow you to eat at your desk, and even let you pay for your fines with canned food that is then given to an Australian charity group. Thanks UTS!

Finally, thanks to Solutions First, specialists in Open Source and Linux solutions and a whole lot more, and who have generously provided me with this web space for longer than I can remember. Cheers guys!

This weeks developments:

• <animateTransform>
• SVGAnimationElement interface
• Fixes to better synchronise the DOM state with the animation state
• A couple of other small fixes

Today I ran up against some questions about zero-length intervals so if you have any insights there I’d be glad to hear from you! I’ve adjusted our timing model based on what I think SMIL intends.

That brings to an end my stint with the NZ office. I had a great time with the fellas here–cheers guys! Or as some people here say, “chur!”

But althought we’ve come a long way I want to emphasise that we still have a long way to go. I’ve updated the status page to give you an idea of the features still remaining to be implemented. In particular, integration with SVG and CSS is a massive task (although it makes up only two rows of the chart) and by far the bulk of animation demos and tests won’t work without this. Also, syncbase timing is a big job.

The good news is <animateTransform> is in the pipeline (ready for review any day now) and for maybe the first time ever, there’s a little bit of momentum behind SMIL.

Update 16 Feb 2011: Thanks to Patric Conrad for a Belorussian translation!

Here’s the low-context summary:

• Daniel Holbert has been taking on this work and pushing it along steadily (thanks a million Daniel!!)
• I’ve joined the Auckland office for my summer break (from December to the end of January) to work full-time on SMIL.
• A (very) basic patch is nearly ready to land after it undergoes some final review and rework. After that SMIL should be on the trunk but disabled by default. I’ve updated the status page to reflect the features of this patch.
• A proper implementation of <animateTransform> is also ready but needs review. I’ve written up (in painfully boring detail) some spec issues I encountered regarding <animateTransform>.

Next on the agenda I hope to be working on syncbase timing.

Thanks again for all your support and Happy New Year! Godt nytår! あけましておめでとうございます！ 新年もよろしくお願いいたします！

From now on, if you want to track the progress of SMIL in Mozilla I recommend:

• #216462 Implement SVG (SMIL) Animation
• tor’s weblog

As for me, I’m travelling around Asia (check the blog [removed] if you’re really curious), so unless someone can sponsor me to work on this in Asia I can’t really offer much time to the project.

Thank you to everyone who helped me to get SMIL this far. I hope that someone else can pick it up.

Progress on SMIL continues, albeit in slow motion. Just a really quick note for those one or two people who want to know what’s going on:

• Not only does it compile it now runs too!
• All my visual tests pass again
• All my unit tests pass again
• My early attempt at <animateTransform> is up and running again and seems to work.

I need to do some tidying up before it’s ready for review. Most of all:

• Some deCOMtamination
• Making better use of Moz utilities (string iterators, nsTArray etc.)
• Removing redundant code
• Fixing the scope of the animation controller

It’s hard to give a timeframe for this – it depends a bit on my workload with other things (Japanese, Bible college, surfing, life – not to mention my day job). Hopefully a month?

As for new feature work, I’ll have to re-negotiate with work before I can do that. So I’d really appreciate any help at all. The SVG guys have already been incredibly helpful and have begun preparing the SVG code so it can be animated more efficiently. Thanks guys!