It’s about time…

・Archive ・SMIL

Firefox 4 is going four dimensional! Time dimensional! (Ok, for those who know physics, just pretend 🙂)

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:

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:

<animate attributeName="stroke-dashoffset" from="0" to="90"
  dur="1s" repeatCount="indefinite" fill="freeze"
  begin="video.playing" end="video.pause; video.ended"/>

Demo of video with SMIL-animated icon synchronised with the video playback state

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.

Woah woah woah! Example of a SMIL-animated SVG filter applied to HTML content. (Hint: try selecting the text)

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.

Previous Post
Synchronising SMIL

Comments

James

It’s interesting that the first demo, while smooth when hovered, seems to use 60% cpu just being visible.

James

(should I file a bug?)

Latest Nightly (http://hg.mozilla.org/mozilla-central/rev/2593c8c8af8b)
Windows 7 x86
D3D9 layers on
D2D, DWrite off
nVidia 6800GS

Daniel Holbert

James: You’re likely experiencing a version of https://bugzilla.mozilla.org/show_bug.cgi?id=562815

Pavan

love u FF!! ur too cool n way beta den chrome!! keep up d good work ff!! gog go opensource :D

Brian

Thanks Pavan! We’ll do our best! Thanks for the encouragement!

Leave a reply

Most markdown like **bold** and _italic_ is supported.

Never shown. Only used for looking up your gravatar.

Optional
https://