Web Animations/Requirements

The following requirements are drawn in a large part from the animation-related parts of SVG 2 Requirements Input as well as the comparison between SVG Animations and CSS Animations and the list of limitations in SVG Animations.

Existing functionality

Timing

• Repetition
  • API by iteration count
  • SVG by iteration duration
• Begin delay
• Begin triggers
  • <interactive> by events—leave this to host language?
  • Wallclock [1]
    • May want to deprecate
• Cancellation
  • <interactive> by events etc.?
• Restarting
• Multiple scheduled intervals
  • Might want to simplify SMIL's behaviour here, e.g. say "end always includes indefinite"? Do we need end at all? [2]
    • Could define single intervals at the API level, leave multiple intervals only in SVG—isolates complexity to SVG
• Timing functions
  • cubic bezier curve
  • discrete steps
  • paced (SVG)
  • CSS allows mixing types within an animation, SVG does not yet
• Key-framing
• Synchronisation (SVG)
  • Issues with SVG's synchronisation:[3]
    • Complex (cycle detection, interaction with animation sandwich)
    • End values can't change the duration of animation (i.e. speed), only cut it off
• Reversing behaviour [4]
  • Need to define how timing functions are reversed (CSS Transitions and CSS Animations differ on this?; not in SVG)

Animation

• Combining underlying value (SVG)
• Combining with other animations (SVG)
• Combining with itself (accumulation) (SVG)
• Fill
• to-animation. Both SVG and CSS feature this kind of animation. In SVG there are a lot of issues here:
  • Discrete to-animation, was counter-intuitive but is now fixed [5][6]
  • Frozen to-animation is still broken [7][8]
• Linear/piecewise-constant interpolation
  • Rounding behaviour for integers—trying to resolve inconsistencies (SVG WG ACTION-3223)
  • Floats
  • Linear transitions between certain discrete value properties (e.g. text-anchor) [9]
  • Colours
  • Gradients and paint servers in general
  • Transforms—defined by combined Transforms spec?
    • Clarify behavior of animating transforms (i.e. integrate with CSS Transforms, deprecate old animateTransform) [10][11][12]

Animation target

• Animations should be able to target a series of properties/attributes
  • Ultimately this requirement is about re-using timing information. E.g., it could be addressed by defining animation primitives that each target only a single property/attribute, but which can be combined in a group and the timing specified on the group.

Integration

• Must define interaction with CSS cascade [13]

API

• Pause control
  • per animation (CSS)
  • per document (SVG)
• Get document current time (SVG)
• Set current time (seeking including backwards seeking) (SVG)
• Animation events
  • SVG has TimeEvent and CSS has AnimationEvent. Perhaps we can make TimeEvent a subclass of AnimationEvent and then deprecate TimeEvent?
  • Can we make TransitionEvent a subclass of AnimationEvent as well?
• Must enable automated testing of other features (i.e. probably need at least ability to pause, seek, and query animated values)

New features

Timing

• Begin triggers
  • P3 Extend accessKey support to DOM 3 key identifiers? [14]
• P2 (Brian,Shane) / P3 (Rik) Adaptive duration (dur="auto")
  • Calculate duration based on synchronisation conditions (i.e. anim A ends when B starts so adjust duration to match)
    • Not sure how this would work with repeating behaviour though
  • Calculate duration based on pace (e.g. pace="10px/s")[15]
• P1Time containers [16][17]
  • Including speed control (at least non-negative) [18][19]
• P1 (Brian) / P3 (Shane) → needs discussion Ability to start animations before document load
• P2 Custom easing functions

Animation

• P1 (Shane) / P2 (Rik, Brian) Motion on a path
  • P2 More general functional syntax [20]
• P1 (Shane, Rik) / P2 (Brian) <interactive> State machines
  • How does this compare with SMIL's chapter on State?
• Interpolation
  • P2 (Brian) / P3 (Shane) / No! (Rik) Colours—allow spaces other an sRGB? linearRGB (SVG can already do this)? HSL?
  • P2 Simpler animation between two paths [21]
    • How about animating from a <rect> to a <circle>?
  • Inverse Kinematics—2012-02-22 Not so useful after all
• Serialization of animations

Animation target

• P1 Animations should be re-usable (e.g. specify a target with a CSS selector, re-use Animator objects)
• P2 (consider other templating efforts) Ability to define an composite animation and re-use it.

e.g. this kind of use:

<defs>
  <!-- This animation is used on-demand like a filter -->
  <g id="hoverAnim" time-container="par">
    <animate select="text:first-child" ... />
    <animate select="rect" attributeName="fill" ... />
  </g>
</defs>
<!-- The previously defined animation is instantiated here -->
<g style="animation-name: hoverAnim">...</g>
<!-- This animation is automatically applied
    (to the parent and descendants with "className" class) -->
<g select=".className" time-container="par">
  ...
</g>

• This is already somewhat possible with CSS. The new feature is being able to group animations together into a set and apply them elsewhere.

Integration

• P1 Animations should be able to target animatable CSS properties on HTML or SVG, and animatable SVG attributes
  • Incorporate Patrick's proposal for targetting SVG properties from CSS into this spec?
• P1 (might want to consider <video> separately) Need to integrate with <audio> and <video> (whether hosted in HTML or SVG)
  • What sort of features are required here? Probably need to think about use cases for this. We don't want to reproduce SMIL here.
  • Synchronisation with start and end
  • Synchronisation with progress events?
  • Streaming media and sync tolerance control? (SVG Tiny 1.2 has this)
• Need to have a story for how to integrate subtitles
  • → 2012-02-16 Shane to look into this
• Integration with <canvas>? WebGL? Other standards?
  • P1 (Shane), P2 (Rik), P3 (Brian) Define how to integrate other specs
• P2 (Brian), P3 (Shane,Rik) Define behaviour for static situations
  • printing
  • snapshotTime?
  • discussion about this taking place on svgopentype list. For SVG inside fonts you need a static version for printing but snapshotTime probably isn't what you want since (a) it's expensive to calculate (you have to build the whole timegraph, and (b) it's an unnecessary burden on static-only implementations
• Integration with HTML
  • For element syntax, probably still wrap in <svg>, i.e. <html><svg><animate .../></svg></html>
    • If it proves popular, might able to persuade HTML WG to allow it directly
  • But it would also be useful to be able to define animations in a separate file and overload animation-name (or add animation?) to point to a url (like we can already do with other SVG properties on HTML), e.g. .target { animation-name: url(animations.svg#a1); }
• Integration of SVG and CSS
  • Do we allow animation-iteration-count to apply to SVG's <animate> elements?
  • If so, do we make animation-iteration-count a presentational attribute as well?
  • Or do we define a mapping animation-iteration-count (CSS) → iteration-count (SVG pres attr)
  • Or even animation-iteration-count (CSS) → iterationCount (SVG pres attr), to match the API attribute (WebIDL attributes normally use camel case)

Accessibility

(2012-02-16 Shane to look into this, produce a wish list)

• 2012-03-02 Thanks to Shane's research, the primary requirement here seems to be integration with the Timed Text API
• What does it mean for animations to be accessible?
• Ability to annotate animation triggers with role identifiers?
• Ability to programmatically identify animation triggers to support alternative input methods?
• Speed control is probably one issue (I think this came up in SVG 1.2)
• If animation objects created via the API are never bound to the document in any way, does that make them unavailable for alternative presentations? Do we need to make a way to fetch animations that aren't in the doc?
• What else?

API

• Pause control
  • P1 per time container
• P1 Get time container current time
• P1 Something better than SVG's API for querying animated values if such an API is even needed [22]
  • This is a difficult but important issue
  • One existing proposal, rect.width.px to get base value (likewise rect.width.em etc.), then rect.width.anim.px for anim values?
• P1 Ability to query motion-on-a-path values (existing proposal)
• P1 Ability to create anonymous (i.e. not bound to the document) animations via script?
• P2 Ability to query an animation element/animated element for currently running or scheduled animation objects
  • Timeline API—make it easy for tools to show a visual representation of animation intervals past and future [23]
• Doug suggests we "get in touch with Mike Bostock, DmitriB and other animation script lib authors to ask what they want to see in an API"

Error handling

• P1 Needs to be better defined. SMIL/SVG's handling is too strict requiring all animations to stop. [24]

Liveness (and tree surgery)

• P1 Need to define what happens when animation attributes and elements are modified whilst in play [25]
  • This would probably be required both at the API level and host-language level, e.g. need to define (a) what happens if the duration property of an animation object is modified whilst in play (or make it readonly), and (b) what happens if I modify the dur attribute on an animation element, i.e. which animation objects are updated? Active ones or just future ones?
• Must provide tests for document surgery whilst animation is in play

Testing

• P1 Need tests for every feature (automated where possible but prefer ones that whose result can be easily confirmed when run manually too, e.g. turns the canvas green on pass)

Prioritization

So far, we have the following.

Rik:

1. Synchronisation. Within groups/descendant animation
2. Synchronized javascript interfaces = a way to get around the asynchronous behavior of SMIL/CSS animation
   • If you have an animation of 2 objects and you want to switch out one of the objects with another object (using the animation-end event), there is no way to keep the 2 animations in sync
3. Better API's to control animations so you don't have to muck with CSS style names
4. Custom easing (not that important, nice to have)

Shane:

1. Better support for widget behaviors (this is basically some form of the proposal we've been working on)
2. Better support for paths (actually this is something SVG has that CSS doesn't, so it'll probably end up in there anyway)

Brian:

1. Time containers

Based on further discussion, we've annotated the above list of new features according to the following categories:

• P1 Must have, cannot ship the spec without this.
• P2 Really want, but can put off to another version if absolutely necessary.
• P3 Nice to have if possible, but can live without.