F2F/Sydney 2012/Agenda/Animations/WebAnimations

From SVG
< F2F‎ | Sydney 2012‎ | Agenda
Jump to: navigation, search


SVG Animation (based on SMIL) and CSS Animation offer some similar features for animating Web content. Harmonising these two technologies has been considered on a number of occasions but a path forward has yet to be established. In response to a feature-by-feature comparison of the two technologies the question was raised, “What are the animation features required, prioritised by use case?” (Meeting minutes which lead to Action-48) although a closely related question was, “What would it take to make CSS Animations achieve feature parity with SVG Animations?”

This document attempts to address these two questions and then present a proposal for advancing Animation on the Web.

Audience: This proposal has been prepared for the SVG F2F in Sydney, January 2012. It is intended that feedback from that discussion will guide a more concrete proposal for the next combined CSS and SVG (FX Task Force) meeting.

Prepared by Brian Birtles, Mozilla Japan, Jan 2012.

What is needed to bring CSS up to par with SVG?

Following is an overview of the more significant features present in SVG Animation but not in CSS Animation.

(At the risk of triggering unnecessary discussion about syntax I've put forward some examples of how these features could possibly by incorporated into CSS Animations including syntax. These aren't serious proposals, just an attempt to show in a concrete fashion how these features relate to existing features.)


A major difference between SVG Animations and CSS Animations is the timing model. CSS Animations is event-based while SVG Animations combines an event-based model with a scheduling model.

T1) An absolute time reference. The start time of CSS Animations is defined as follows:

The start time of an animation is the latter of two moments: the time at which the style is resolved that specifies the animation, or the time the document's load event is fired.

CSS Animations, section 2 Animations

That can be a bit too imprecise, particularly when dynamically adding and synchronising animations, and leads to hacks like getting .clientTop to force style resolution (e.g. bug 649247).

With SVG Animations, time containers provide an absolute time reference. This enables a number of features including the following three:

T1a) Global control of animations independently of when they are created. For example, if it is necessary to have all animations cease at a certain time, e.g. t=5s, end="5s" will produce the required behaviour regardless of when the animations are added to the document.

T1b) Script-based synchronisation of animations. (Declarative synchronisation is considered later.) Not only is it possible to synchronise animations with fixed absolute times (e.g. set begin="2s" on two animations) but such absolute times can also be calculated dynamically using SVGSVGElement.getCurrentTime and/or SVGAnimationElement.getStartTime. (So that, for example, animation B starts 3s after animation A, regardless of how far A has currently progressed.)

T1c) Predictable start behaviour. SVGAnimationElement.beginElement will ensure the animation starts at the current time when it is called (as returned by SVGSVGElement.getCurrentTime) not at style resolution time. Likewise for beginElementAt, endElement, and endElementAt.

If introduced, what might this look like in CSS Animations?

  • Perhaps a starting point would be to define a document time container for HTML5 (i.e. a document time zero) which other time containers are relative to (including <video> etc.).
  • In doing so such a zero time should ideally allow animations to start before the document load event fires (e.g. for displaying spinners etc.)—SVG Tiny 1.2 addresses this with timelineBegin="onStart".
  • In order to make most use of the absolute timeline, it would be necessary to introduce syntax. For example,
 animation-start: docstart | auto

Where docstart would make animation-delay relative to the document timeline. This could then be extended to support alternative time containers later.

  • In order to provide script-based synchronisation, it might be useful to add DOM interfaces to inspect the start time of the current animation in document time.
  • Likewise, a means of inspecting the document time (getCurrentTime) would be needed.
  • Once it becomes possible to know precisely when an animation will start and finish, it also becomes necessary to define precisely what values the animation takes at the end-points like SMIL's end-point exclusive timing.
  • Would something like SVG's beginElement() (which is guaranteed to start the animation immediately, i.e. at the current time container time, without being dependent on style resolution) be useful?

Vincent Hardy expressed concern about CSS Animations' timing model (or lack thereof) at Seattle so perhaps the Adobe guys have a better idea of the issues here?

T2) Ability to schedule multiple intervals.

SVG Animation allows scheduling multiple intervals, e.g. begin="0s; 5s". This is mostly useful when combined with other begin types (e.g. begin="0s; elem.click; animB.end") but can be useful even with just fixed times such an exported cartoon where the same sequence is reused a number of times. It also means that restarting an animation can be done declaratively.

If introduced, what might this look like in CSS Animations?

At first it might seem to simply involve extending animation-delay to allow multiple values per corresponding animation-name. However, it is really a fundamental change to the timing model. The concepts of animation start and end take on different meanings. For example, what should the animated value be inbetween intervals, when animation-fill-mode is backwards or forwards?

It also becomes necessary to define what happens in the case of overlapping intervals. SVG Animation uses restart="always"|"whenNotActive"|"never" for this.

T3) Ability to declaratively abort animations.

SVG Animation uses the end attribute to provide conditions that will abort the animation.

Examples of use:

  • Ensure all animations cease at a certain time.
  • Ensure an animation ceases 2 seconds after a mouseout event.
  • Ensure animation B ceases 1 second after animation A starts.

If introduced, what might this look like in CSS Animations?

I suppose it would involve additional syntax, animation-end? One issue which is worth considering is the relationship with animation-fill-mode. Should the fill value be applied for this kind of abort? And if so, which value?

SVG Animation treats this kind of end like any other, i.e. if fill="freeze" the last value continues to apply. However, sometimes it is useful to define abort behaviour such that the animation effect is removed completely (whilst also providing fill behaviour for regular ends). SMIL can produce this with time containers, but it is very difficult with SVG Animation.

T4) Ability to synchronise animations.

SVG Animation provides syncbase timing which allows the begin and end times of an animation to be calculated based on other animations.

For example,

 <animate begin="animB.begin+100ms; animC.end-2s;" end="animD.begin-1s"/>

Rules are defined for detecting and breaking cycles in dependency chains whilst permitting valid and useful cyclic dependencies. For example,

 <animate id="animA" begin="0s; animA.end+1s" dur="5s"/>

There are other means of achieving synchronisation but unlike (a) script-based timing, syncbase timing is simpler to author and resilient to changes in the timing such as pauses, and unlike (b) sychronisation using events (see T8), syncbase timing allows negative time offsets to behave as expected.

If introduced, what might this look like in CSS Animations?

  • From a syntax point of view, and assuming the ability to schedule multiple intervals (T2) was incorporated into CSS Animations, one possibility would be to extend an animation-start keyword from T1 to allow multiple values. For example,
  animation-start: (docstart, auto, swirl-anim#begin)
  animation-delay: (6s, 0, -3s)

Here swirl-anim is an animation-name.

  • One issue here is to define what it means to synchronise with the begin of another animation. It would presumably not be the start of the animation, but rather the start + animation-delay.
  • Much of the complexity in SVG Animations comes from updating syncbase dependencies as the timing model changes. Likewise CSS Animations would need to define what happen in the face of changes to the the dependent base animation.

T5) Ability to seek the document timeline.

SVG Animations allows seeking to an arbitrary time using SVGSVGElement.setCurrentTime. This assumes an absolute time reference is available (T1. Of course, it would be possible to produce an API that used only relative offsets).

Reversing is particularly interesting. Roughly speaking, SVG Animations remembers all the state up to the seek time, but discards all state after that time. For example, imagine an animation of duration 10s that was started by script at t=3s, and terminated by script at t=6s. At t=7s, a seek is performed to t=4s. The animation will be in play and will continue to play until t=16s. (Actually, it's more complicated than that. Strictly speaking begin times aren't reset by a backwards seeking but reset behaviour will mean that most of them will get reset in due course anyway.)

Animation events are not fired when seeking unless the net result of the seek is that the animation changes start from playing to not playing or vice versa.

If introduced, what might this look like in CSS Animations?

  • This would most likely tie in with defining a document time container for HTML5 (see T1). In doing so it would make sense to extend the appropriate HTML interface to add get/setCurrentTime-like interfaces.
  • As with SVG Animation, just what state is preserved would need to be defined.
  • Likewise the behaviour with regards to dispatching AnimationEvents would need to be defined.

T6) Ability to pause the document timeline.

Along with seeking the document timeline is the ability to pause all animations in the document (actually, time container).

If introduced, what might this look like in CSS Animations?

  • As with T5, extending the appropriate HTML interface?

T7) Ability to specify repeating behavior by duration rather than iteration count.

In addition to repeatCount (which roughly parallels CSS Animations' iteration-count), SVG Animation provides repeatDur. If both are specified, the minimum of the two is used.

This might just seem like syntactic sugar but it begins to become useful when used in conjunction with arbitrary time containers (F1, which SVG Animation doesn't currently offer) where the simple duration of the child animations is not known. (The same is true of min and max which I haven't covered in this document.)

If introduced, what might this look like in CSS Animations?

  • animation-iteration-duration? Along with corresponding definitions of what to do when animation-iteration-count is also specified.

T8) Ability to declaratively trigger animations from abitrary events.

SVG Animations allows animations to be triggered from arbitrary events on arbitrary elements, e.g. a mouse click on an otherwise unrelated element, the playing event of an HTML5 video (live example).

In order to avoid sync drift, the timestamp in the event should be used as the time to synchronise against rather than the time container time when the event is received. See SMIL 3.0, 5.6.3

If introduced, what might this look like in CSS Animations?

  • Introducing this necessitates T2 (multiple intervals) and therefore we'd need to define restart behaviour, e.g. if an animation triggered by a click is still playing when another click occurs do we restart or ignore? This is discussed under T2.
  • As for syntax, just another type of animation-start ? Likewise animation-end.

Animation values

SVG Animation provides a number of features for calculating and combining animation values not present in CSS Animations.

A1) Motion on a path.

<animateMotion> allows animation along a path including a non-linear path (using SVG path data syntax). The path of an existing shape can be traced using the <mpath> element (i.e. the path data does not need to be duplicated.)

<animateMotion> operates by supplying a supplemental transformation matrix applied after any <animateTransform>. (The order if which this matrix is applied has been discussed at length on www-svg. A couple of the key messages in a discussion that spanned a few months: [1] [2] [3] [4])

The rotate attribute allows the target to be rotated by a fixed degree or by the angle of the direction of the motion path (rotate="auto|auto-reverse").

Importantly, using calcMode="paced" (calcMode is similar to animation-timing-function in CSS Animations) will produce constant velocity along the path.

In December 2011, the SVG WG resolved to extend this path-based animation to other pairs of attributes (function-based input). See the description of the feature by David Dailey and the conference call minutes.

If introduced, what might this look like in CSS Animations?

  • At Seattle, Daniel Holbert raised the point that <animateMotion> would be difficult to convert to CSS, even with attr-property mappings. Could it be realised as a special case of animation of the transform property? How would this work inside a @keyframes rule?
  • Furthermore, re-using existing paths (<mpath>) would require yet another variant syntax.

A2) Combining with the underlying value.

SVG Animations provides additive animation through:

  1. additive="sum"
  2. by-animation (no from attribute, just by)
  3. to-animation (no from attribute, just to)—produces a special kind of addition

Such animations add to the underlying value which for now we will consider to be the base value of the attribute or property being animated (adding to an underlying animation is A3).

CSS Animations can produce a similar effect to to-animation by not specifying a 0%/from keyframe (with the qualification that unlike SVG Animations, once the animation begins, any changes to the base value will be ignored.)

Regular additive animation and by-animation do not appear to be available.

If introduced, what might this look like in CSS Animations?

  • On the Wiki for the discussion at Seattle, July 2011 Dean Jackson added a note that additive properties have been proposed for CSS Animations but I can't find that proposal or determine if it relates to combining with underlying values or just combining with other animations (A3).
  • Requires defining what addition means for each of the types targetable by CSS Animations.

A3) Combining with other animations.

Closely related to the ability to add to the base value of an attribute or property in SVG Animations is the ability for animations to add together. This allows, for example, an animation that spins an element to be combined with an independent animation that moves it (since they both target the transform attribute).

CSS Animations does not currently allow this:

In the case of multiple animations specifying behavior for the same property, the animation defined last will override the previously defined animations.

CSS Animations, section 2 Animations

In order to define the order of addition (important since some types of "addition" are not commutative such as transforms which post-multiply) as well as to resolve which animation wins when animations are NOT additive, SVG Animations uses the sandwich model which prioritises animations according to:

  • start time, then
  • time dependency, then
  • document order

If introduced, what might this look like in CSS Animations?

  • As mentioned under A2, there may already be a proposal for adding this to CSS Animations.
  • As with A2, requires defining addition for all animatable properties.
  • Does supporting something like this deviate too much from usual CSS specificity and inheritance rules? Or are there other properties that behave like this?

A4) Combining an animation with itself.

Finally, SVG Animations also allows a repeating animation to add to itself (accumulate="sum").

If introduced, what might this look like in CSS Animations?

  • Requires introducing a keyword such as animation-iteration-addition?
  • In order for this to behave correctly, something akin to SVG's end-point exclusive timing model needs to be defined.
  • As with A2, requires defining addition for all animatable properties.

Document structure

D1) Defining an animation alongside its target.

By default, SVG Animations target their parent element. This allows a compact syntax without ID references (or class attributes) and simplifies document manipulation (e.g. serialising a document fragment, dynamically adding an animation to an element). For example,

<rect width="100" height="100">
  <animate attributeName="x" from="0" to="100" dur="5s"/>

If introduced, what might this look like in CSS Animations?

  • As Anne van Karsten points out something similar should be possible with <style scoped>.
  • I wonder if more could be done for the dynamic addition case though since adding the following fragment by script is considerably more complex than adding an element and setting attributes:
<style type="text/css" scoped="scoped">
  * {
    animation-duration: 3s;
    animation-name: slidein;
  @keyframes slidein {
    from {
    to {
  • Perhaps some API is needed for this?

Features that do not currently exist in either CSS Animations or SVG Animations

This document addresses features in SVG Animations not in CSS Animations. There are, of course, features in CSS Animations not in SVG Animations such as reversing, and the ability to use a CSS selector to choose the animation target(s). These differences are described in the comparison of SVG Animation and CSS Animation presented at Seattle in 2011.

Following is one feature that does not exist in either SVG Animations or CSS Animations. The purpose for including this feature here is that it has been previously proposed for SVG, included in a limited form in SVG 1.2 Tiny and is a likely candidate for inclusion in SVG 2.0.

F1) Arbitrary (nested) time containers.

This feature has previously been proposed for SVG and is available in a limited form in SVG 1.2 Tiny in the <animation> element and in my view must be part of any future version of SVG Animations.

Briefly, time containers provide the ability to establish a new timeline (relative to the parent time container) that:

  • can be paused and seeked independently of other (non-descendant) time containers, and
  • can have constraints applied at a container level that apply to all children (e.g. repeatDur, max, begin), and
  • can have semantics controlling the relationship of child animations (e.g. a container where all the child animations run in a chain like SMIL's <seq>; or one where they run in parallel providing a powerful form of synchronisation), and
  • can be nested.

In considering uses cases for animation on the Web we will also consider how this feature might be applied.

If introduced, what might this look like in CSS Animations?

Unfortunately, this feature would be particularly difficult to represent using CSS since much of its utility comes from being able to nest different types of containers in a hierarchy. This hierarchy may or may not correspond to the hierarchy of the content being animated.

Use cases

So far we have considered what would be needed to bring CSS Animations up to feature parity with SVG Animations but that is not to suggest all these features should be added.

In this section we consider some use cases in order to prioritise those features. The focus is on existing real-world use cases rather than fictional use cases (since it is probably possible to imagine a use-case for any feature given a bit of creativity! Also fictional use cases tend to be too simplistic and don't scale).

Case 1: A flashy button

Sometime in 2010, the challenge was put out to create a Flash button using HTML5.

An SVG version is here: http://brian.sol1.net/svg/demo/button.svg

The SVG Animation features listed above used in this case are:

  • T2) Ability to schedule multiple intervals
    • The sliding of the button text left to right both on mouse over and mouse out is the same animation but with multiple begin conditions. If the users quickly mouses over the button and back out again before the first animation finishes, restart="whenNotActive" ensures that the animation is not triggered a second time.
  • T3) Ability to declaratively abort animations
    • Used to abort the animation if the user mouses out while the animation is still playing. This particular arrangement is probably already possible in CSS Animations.
  • T4) Ability to synchronise animations
    • Used to trigger the background frame-based animation when the initial transition animation finishes.
  • T8) Ability to declaratively trigger animations from abitrary events
    • Used to trigger animation on the label and filters based on events that occur on an independent <rect>.
  • D1) Defining an animation alongside its target
    • While this is used extensively, it's not particularly significant in this case.
  • F1) Arbitrary time containers
    • The frames that make up the background animation could naturally be represented using syncbase timing (T4) but this makes it difficult to cancel the chain on mouseout. If something equivalent to SMIL's <seq> element where available not only would cancelling be simple (just cancel the container) but syncbase timing would also not be needed.

Another note about this case is that it is entirely declarative. This is important for this particularly kind of use case since ideally UI widgets should not have to run script for their visual display. Indeed, in many cases (such as SVG cursors) they cannot.

Case 2: Collaborative animation

The ParaPara heiga group have been running workshops where participants create simple frame-based animations on tablets and upload them to a central server where they are combined to form a longer narrative that is projected onto a screen.

The recent Kyoto workshop used an iOS app for the drawing, and HTML5 canvas for the combined display.

Mozilla Japan has been helping to create a version using only open Web technologies including SVG including SVG Animation. The animations are drawn and animated using SVG, and the final animation is likewise an SVG animation.

The SVG Animation features listed above used in this case are:

  • T1) An absolute time reference
    • T1b) Script-based synchronisation of animations
      • SVGAnimationElement.getCurrentTime is used to fetches the planet's current animation time to work out how far it has rotated and therefore how long to make the character's animation so it finishes at a certain point.
    • T1c) Predictable start behaviour
      • beginElement is used to insert an animation whose duration is calculated based on the currentTime. Therefore the begin time needs to be accurate or else the animation will end at the wrong point.
  • T4) Ability to synchronise animations
    • Used to chain together the frames of the character animation.
  • T7) Ability to specify repeating behavior by duration rather than iteration count
    • Used in calculating when a character's animation should end that has started part-way through.
  • A1) Motion on a path
    • Used to make the characters walk on the planet (including the auto-rotation feature).
    • Re-use of an existing path (<mpath>) is used to make characters walk on the planet surface
  • A2) Combining with the underlying value
    • Adds the planet rotation to the planet's existing translation.
  • D1) Defining an animation alongside its target
    • Used to easily add the animation to each frame and easily add motion animation to the characters as a whole.
    • Makes extracting the animation from it's SVG document for sending to the server simple. Simply clone the document fragment with the frames and all the animations are included.
  • F1) Arbitrary time containers
    • Chaining of frame-by-frame animations would be a lot simpler with something like <seq>.

Once again, the declarative nature of SVG Animations is beneficial here since the characters are embedded in the planet animation as <image> elements. This simplifies incorporating them and also provides a degree of security.

Furthermore, we would like to be able to email participants the character they designed so they can post it on their blog—a process which is much easier if script is not required since it may be blocked by a mail client, and will not run if the file is linked to by an <img> element.

Case 3: Animation tool

This is an ongoing project to create an easy-to-use tool for creating cutout animations with open Web technologies.

The SVG Animation features listed above used in this case are:

  • T1) An absolute time reference
    • Used to set up the timing of the steps such that they can be later replayed (non-interactively). Probably easier than managing a web of synchronisation links in this case.
  • T4) Ability to synchronise animations
    • NOT actually used in the current very limited prototype but highly likely to be used in the near future such as when scenes are added.
  • T5) Ability to seek the document timeline
    • This feature is absolutely fundamental to this application. Each time the back and forwards buttons are selected the timeline is seeked and the animated values are the seeked-to time are read to create temporary transformations while dragging.
  • T6) Ability to pause the document timeline
    • Hand-in-hand with seeking is pausing the document the seeked-to time.
  • D1) Defining an animation alongside its target
    • As with the collaborative animation use case, used to extract the actual scene from the SVG document (which includes overlays etc.) with its animations intact. Also simplifies the addition of animation to nodes.
  • F1) Arbitrary time containers
    • This would allow the UI overlays to be in a separate layer that is animated independently of the animation being edited (and possibly previewed).

As with the collaborative animation, the animations produced by this tool should be emailable and remotely hostable (as <img>) so being able to describe the animation declaratively is important.


More uses cases are needed to make any strong recommendations. Following is a very tentative prioritisation based partly on the use cases above, and partly on hunch.

Pretty certain:

  • T4) Ability to synchronise animations—synchronisation is fundamental to animation and relying on events leads to sync slew.
    • T1c) Predictable start behaviour—scripts need to be able to synchronise newly generated animations with already running animations
  • T5) Ability to seek the document timeline—critical for complex animations
  • T6) Ability to pause the document timeline— " "
  • A1) Motion on a path—a useful effect that's difficult to do by other means
  • F1) Arbitrary time containers—very useful for complex animations and complex applications (particularly use case 3, the animation tool)


  • T1) An absolute time reference—it's probably possible to get away with not doing this if there are good synchronisation features and a means of starting an animation immediately.
  • A2) Combining with the underlying value—if A3 is useful, then for consistency it probably makes sense to include this as well (akin to SMIL's underlying value concept).
  • A3) Combining with other animations—event though this didn't occur in any of the use cases, the ability to have independent transform animations targetting the same element seems fairly fundamental

Less clear:

  • T2) Ability to schedule multiple intervals—the main reason this might become necessary is that if we support triggering animations from arbitrary events
  • T3) Ability to declaratively abort animations—seems fairly fundamental in the button case but admittedly it is complex and relies on being able to receive arbitrary events that are not available in most of the scenarios where declarative animation is critical
  • T7) Ability to specify repeating behavior by duration rather than iteration count—convenient but not critical. It can always be calculated. It may become necessary in relation to arbitrary time containers (F1) however.
  • T8) Ability to declaratively trigger animations from abitrary events—as mentioned above, it's very useful but can be done with script and in the cases where script is not an option, often events are also not available
  • D1) Defining an animation alongside its target—this is really just convenience, but so frequently used that it seems important
  • A4) Combining an animation with itself—didn't occur in any of the use cases but might still be useful

Proposal: Web Animations

The above prioritisation represents features deemed useful for animation on the Web. However, the question remains as to what is the most suitable vehicle for delivering these features.

Time containers are one feature that seems difficult to realise in CSS and much better suited to an element syntax. Likewise, questions have been raised about motion on a path.

My proposal:

  • Create a simplified version of SVG Animations that tracks CSS Animations syntax and behaviour but offers:
    • hierachical semantics,
    • compact syntax,
    • motion on a path,
    • simple DOM manipulation, and
    • animation and content side-by-side.

The ultimate goal is one doc: Web Animations 1.0 that includes CSS Animations and a more fully-features element syntax.

The precedent for this kind of arrangement is Filter Effects 1.0.

This supports the notion of using elements/presentation attributes for actual content, and stylesheets for styling. For the case of an SVG cartoon (like Flash movies) the animation is content, not styling of content.

The details

This is really draft. It's just some ideas to stimulate your imagination.

<anim> Element

(I really want to call this <animation> but SVG Tiny 1.2 already took that ☹ Obviously <anim> won't cut it.)

Selecting the target element(s):

  • select—uses CSS selectors (much needed)
  • href—id ref
  • nothing—as with SVG Animations applies to parent elem
  • BUT, if the animation is summoned via animation-name, then it applies to selected element(s)

Selecting the target attribute(s):

  • Not sure about this. We could add attr (akin to attributeName from SVG Animations) but there should also be another mechanism that better parallels CSS Animations, especially the ability to target multiple attributes/properties, e.g. <anim attr="left; top" values="50, 100; 30, 20">, or even:
<anim delay="5s" ... >
  <keyFrame attr="left; top" val="50; 30"/>
  <keyFrame attr="left; top" val="100; 20"/>

Other attributes align with CSS Animations, e.g.:

  • delay = animation-delay
  • iterationCount = animation-iteration-count
  • timingFunction = animation-timing-function
  • etc.

Rounding behaviour and other minor differences will align with CSS animation.


  • NO <animateTransform>
    • just attr="transform", attr="patternTransform" etc. or whatever the syntactical equivalent is.
    • targets a transform LIST (unlike <animateTransform> which only sets a single value)
    • interpolate consistently with CSS transforms
  • NO <animateColor>
  • If possible get rid of <animateMotion> and just introduce appropriate attributes / syntax to make it available on regular <anim> elements (or whatever they end up being called). We already resolved to allow this function-based syntax elsewhere anyway.
  • Probably can get rid of <set> as well and just make it another timingFunction value

There are lots of other things that can be tidied up at the same time like fixing to-animation.

One difference is that CSS animations divides like so:

Animation call site Animation definition

But with SVG Animation it's all stuck on the animation definition. Need to define override rules (e.g. call site overrides definition).

<animGroup> Element

(timeGroup? syncGroup? timeContainer?)

type="par|seq" (default par)


  • delay
  • end
  • direction
  • iterationCount, etc.

Contains: video, audio, anim, arbitrary content?

  • There's a range of options of what do with other elements such as
  1. nothing
  2. display/hide
  • Need to provide a means of referencing <video> and <audio> elsewhere in the doc

Other issues:

  • Events are common with CSS, i.e. AnimationEvent
  • DOM storage—can we simplify this at the same time?
  • This needs to be able to target HTML too, not just SVG
    • Already possible using inline SVG but could be better integrated

Migration path for authors

  • Possible to make CSS syntax as fallback
  • Web Animations is not backwards compatible with SVG 1.1 Animations but similar enough that a tool could automatically convert them.
    • SVG 1.1 Animations would still be supported (but deprecated) by user agents for some time going forward.

Migration path for implementors

  • Implementations which support SVG Animations can easily add support, e.g.
    1. if we have an end attribute we might want to simplify its behaviour but that can be done by just providing an extra "indefinite" value to SMIL engine to get new end behaviour
    2. for different rounding behaviour, just detect the element name to see which to use
    • Over time, report use of older SMIL elements as deprecated
  • Implementations which don't currently support SMIL just implement the new simpler arrangement.

Steps forward

  • I'd like feedback on the idea of Web Animations. If there is support for the idea I'd like to prepare a more detailed draft for the F2F in Hamburg, May 2012.