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?

15 thoughts on “What do we do with SMIL?

  1. Animation of the viewBox dimensions itself within an SVG to, for example, follow something being animated close-up as it moves around the SVG.

    Like

    1. Yeah, I tried to promote viewBox to a property at one point–partly so you could animate it from CSS but then I ran into trouble with cyclic dependencies between media queries and viewBoxes.

      Like

  2. Same happened to WebSQL. When Mozilla decided to drop in favor of nothing (or maybe IndexedDB which nobody is using), the whole offline storage was getting a mess.

    I’m afraid that we’ll see this now with SVG animations.

    Like

    1. Hi Pete, I don’t think that’s the story. Mozilla never supported WebSQL in the first place so they didn’t drop it (see http://robert.ocallahan.org/2010/06/not-implementing-features-is-hard_03.html). Instead the they implemented IndexedDB which people are using and which is now implemented in all browsers. The Chrome use counter puts it at about 3% of sites (https://www.chromestatus.com/metrics/feature/timeline/popularity/9) which is actually pretty high. requestAnimationFrame comes in at about 5% and no one would question that it is being used.

      I hope we end up with interoperable animation support. I’m disappointed that sites like http://parapara.mozlabs.jp/ will stop working if we don’t either keep SMIL or get suitable alternatives in place.

      Like

  3. Does the CSS Motion Path module support easing?

    Also, how does motion-path work with other transform animations? For cases where I’d like to have a motion path and also animate scale while the element travels on page.

    Do you know if the CSS transforms level 2 draft about ‘translate, rotate and scale properties’ is available somewhere? I tried to google for it, but couldn’t find anything. Is there a reason it doesn’t include the skew property?

    Like

    1. Hi Kari,

      The Motion Path module just defines a property that can be animated so you can use the regular CSS Animation / Transition timing functions to perform easing.

      Motion path transforms are combined with the transform property by premultiplying the resulting transform onto the one defined by the transform property. So, yes, you can combine a motion path animation with a transform animation.

      Sorry, my description of CSS Transforms Level 2 made it sound like it already exists. It doesn’t as far as I’m aware but when it comes time to write it, separate properties for each of the components should be part of the spec.

      Regarding skew, last time we discussed it I think the sentiment was that it’s not very useful and that people are often using it to fake 3D effects when they should just use 3D transforms. Unfortunately I don’t see anything in the minutes of that discussion (http://www.w3.org/2015/02/10-fx-minutes.html#item10) about that. It can be revisited though if there are compelling use cases for it!

      Like

  4. Have you shared these details on the “intent to deprecate” thread? These threads are intended to be non-final public proposals for discussion, rather than “done deals”, so this sort of data would be useful.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s