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.

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

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?

Error handling

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:

Synchronisation. Within groups/descendant animation

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

Better API's to control animations so you don't have to muck with CSS style names

Custom easing (not that important, nice to have)

Shane:

Better support for widget behaviors (this is basically some form of the proposal we've been working on)

Better support for paths (actually this is something SVG has that CSS doesn't, so it'll probably end up in there anyway)

Brian:

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.