View source for F2F/Seattle 2011/Agenda/Animations/Harmonisation

==Executive summary==

The relationship between SMIL Animation in SVG and CSS Animations/Transitions needs to be clearly established in order to guide future development of these specifications. To that end, a brief comparison between the two technologies is provided. Subsequently some concrete suggestions are offered on how we might proceed. Merging the two technologies seems difficult but aligning them may be possible.

==Definitions==

From this point forward, the following definitions will be used:

'''SVG Animation''' = SMIL Animation ''[http://dev.w3.org/SVG/profiles/1.1F2/publish/animate.html as used in SVG]'' (!= SMIL Animation != SMIL 3.0)

'''CSS Animation''' = [http://www.w3.org/TR/css3-transitions/ CSS Transitions] + [http://www.w3.org/TR/css3-animations/ CSS Animations]


__TOC__

==SVG Animation x CSS Animation==

===Animation target===

* <span style="font-weight:bold; color:orange">CSS:</span> a set of properties on matched elements
* <span style="font-weight:bold; color:blue">SVG:</span> one attribute on one element

 <nowiki>
div {
  animation-name: 'diagonal-slide';
  animation-duration: 5s;
  animation-iteration-count: 10;
}

@keyframes 'diagonal-slide' {
  from {
    left: 0;
    top: 0;
  }
  to {
    left: 100px;
    top: 100px;
  }
}
  
<animate xlink:href="#rect1" attributeName="left" from="0" to="100px" dur="5s" repeatCount="10"/>
<animate xlink:href="#rect1" attributeName="top" from="0" to="100px" dur="5s" repeatCount="10"/></nowiki>

'''Summary:''' Target selection fundamentally different. SVG lacks animation re-use (proposed - for example a selector attribute on the animation elements [http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements#Wanted_feature:_re-use_animations])

===Animation values===

Combining with underlying value:

* <span style="font-weight:bold; color:orange">CSS:</span> always overrides underlying style<br/>
* <span style="font-weight:bold; color:blue">SVG:</span> can add to or override in various ways (<code>additive="sum"</code>, by-animation, to-animation)

Combining with other animations:

* <span style="font-weight:bold; color:orange">CSS:</span> [http://www.w3.org/TR/css3-animations/#animation-behavior- only one animation can target a property] (proposal to introduce additive property to CSS animations)<br/>
* <span style="font-weight:bold; color:blue">SVG:</span> can add to or override other animations (<code>additive="sum/replace"</code>)&mdash;complex rules for determining priorities of competing animations (begin time, doc order, sync dependencies)

Combining with itself:

* <span style="font-weight:bold; color:orange">CSS:</span> When an animation repeats it goes back to the start<br/>
* <span style="font-weight:bold; color:blue">SVG:</span> Either returns to start, or builds on final value (<code>accumulate="sum"</code>)

Before/after animation is complete:

* <span style="font-weight:bold; color:orange">CSS:</span> determined by <code>animation-fill-mode</code> property which allows extension in both directions (i.e. before the animation started)
* <span style="font-weight:bold; color:blue">SVG:</span> determined by <code>fill</code> attribute (<code>fill="freeze"</code> means last value continues to apply, i.e. after only)

'''Summary:''' SVG offers a range of features for combining animations together and with the underlying value.

===Animation types===

* <span style="font-weight:bold; color:orange">CSS:</span> Linear/piecewise-constant interpolation
* <span style="font-weight:bold; color:blue">SVG:</span> Linear/piecewise-constant interpolation + animation along a path

Some differences:
* Integers: <span style="font-weight:bold; color:orange">CSS:</span> use <code>floor</code>, <span style="font-weight:bold; color:blue">SVG:</span> [http://www.w3.org/TR/SMIL/smil-profile.html#SMILProfileNS-animation-module round]
* Colors: <span style="font-weight:bold; color:orange">CSS:</span> sRGB, <span style="font-weight:bold; color:blue">SVG:</span> sRGB / linearRGB (depends on <code>color-interpolation</code>)
* Paint servers: <span style="font-weight:bold; color:orange">CSS:</span> gradients with same no. of stops can be interpolated, <span style="font-weight:bold; color:blue">SVG:</span> no (but you can animate the gradient itself and its <code><stop></code>s)

'''Summary:''' Interpolation types and methods have some variation.

===Interval timing===

Animation begin

* <span style="font-weight:bold; color:orange">CSS:</span> doc load/style resolution (incl. UI events: <code>:hover</code>, DOM manipulation: <code>setAttribute("class",...)</code>)<br/>
* <span style="font-weight:bold; color:blue">SVG:</span> doc load/events (not just UI)/accesskey/DOM (<code>beginElement</code>)/<u>syncbase</u>/wallclock &#9786;

Begin delay

* <span style="font-weight:bold; color:orange">CSS:</span> <code>transition/animation-delay</code><br/>
* <span style="font-weight:bold; color:blue">SVG:</span> All begin times allow an offset to be applied

Terminating an animation

* <span style="font-weight:bold; color:orange">CSS:</span> remove from <code>animation-name</code><br/>
* <span style="font-weight:bold; color:blue">SVG:</span> <code>end</code> attribute: same sorts of values as begin (a set time/event firing/syncbase etc.)

Restarting

* <span style="font-weight:bold; color:orange">CSS:</span> remove from <code>animation-name</code> and re-add<br/>
* <span style="font-weight:bold; color:blue">SVG:</span> if <code>restart="always"</code> the animation can restart mid-animation if another begin condition is satisfied

Repeating

* <span style="font-weight:bold; color:orange">CSS:</span> <code>animation-iteration-count</code>: >= 0.0 | "infinite"<br/>
* <span style="font-weight:bold; color:blue">SVG:</span> <code>repeatCount</code>: > 0.0 | "indefinite"; <code>repeatDur</code>
 
'''Summary:''' Interval timing is fundamentally different. The CSS timing model is ''primarily event-based'' (animations start when the document loads or a style is resolved). The SMIL timing model combines an ''event-based model with a scheduling model'' (many intervals can be scheduled in advance).

SMIL has complex (and confusing) rules for establishing intervals, e.g.
* Zero-duration intervals ok, but not two in a row
* If there's an end condition and all end times are before the next begin time the animation will not play&mdash;acts like a hard clamp
* Once an interval (other than the first) is started, certain begin/end times are cleared

'''This is a significant difference.'''

===Timing functions=== 

Keyframing

* <span style="font-weight:bold; color:orange">CSS:</span> <code>@keyframes</code>
* <span style="font-weight:bold; color:blue">SVG:</span> <code>keyTimes</code>

 <nowiki>
@keyframes 'wobble' {
  0% {
    left: 100px;
  }
  40% {
    left: 150px;
  }
  60% {
    left: 75px;
  }
  100% {
    left: 100px;
  }
}

<animate attributeName="left" values="100px; 150px; 75px; 100px"
  keyTimes="0; 0.4; 0.6; 1" ... /></nowiki>
  
Timing functions

* <span style="font-weight:bold; color:orange">CSS:</span> cubic bezier curve, discrete steps
* <span style="font-weight:bold; color:blue">SVG:</span> cubic bezier curve (lacks CSS' keywords <code>ease-in</code> etc.), discrete steps (not as flexible as CSS), paced (even pace of change, especially for motion on a path)
 <nowiki>
@keyframes 'bounce' {
  from {
    top: 100px;
    animation-timing-function: ease-out;
  }
  25% {
    top: 50px;
    animation-timing-function: ease-in;
  }
  50% {
    top: 100px;
    animation-timing-function: ease-out;
  }
  75% {
    top: 75px;
    animation-timing-function: ease-in;
  }
  to {
    top: 100px;
  }
}
 
<animate attributeName="top" values="100px; 50px; 100px; 75px; 100px"
  calcMode="spline" keyTimes="0; 0.25; 0.5; 0.75; 1"
  keySplines="0 0 0.58 1; 0.42 0 1 1; 0 0 0.58 1; 0.42 0 1 1"/></nowiki>

Reversing

* <span style="font-weight:bold; color:orange">CSS Transitions:</span> Automatic reversing of animation (does ease-in remain ease-in? Discussion threads: [http://lists.w3.org/Archives/Public/www-style/2009Nov/0302.html] and [http://lists.w3.org/Archives/Public/www-style/2010Jan/0204.html])
* <span style="font-weight:bold; color:orange">CSS Animations:</span> <code>animation-direction</code> - allows alternating direction on repeat; ease-in becomes ease-out. Otherwise separate animation required.
* <span style="font-weight:bold; color:blue">SVG:</span> --

'''Summary:''' Timing functions are mostly comparable (with minor differences, CSS lacks 'paced', SVG lacks keywords and some step functions). However, SVG does not allow mixing types of animation functions (e.g. discrete/cubic bezier/paced) within the one animation definition. Also, SVG lacks any reversing functionality.

===DOM functions===

DOM interfaces

* <span style="font-weight:bold; color:orange">CSS:</span>
** Per-animation: pause/unpause, query pause/play state (<code>animation-play-state</code>&mdash;may be dropped?)
* <span style="font-weight:bold; color:blue">SVG:</span>
** Per-animation: start/stop animation (<code>beginElement(At)/endElement(At)</code>), query start time, current time, duration (interface <code>SVGAnimationElement</code>)
** Per-document: pause/unpause, get/set current time (i.e. seeking, interface <code>SVGSVGElement</code>)

Events

* <span style="font-weight:bold; color:orange">CSS Transitions:</span> TransitionEvent (type: transitionend). Context info: propertyName, elapsedTime
* <span style="font-weight:bold; color:orange">CSS Animations:</span> AnimationEvent (type: animationstart/animationend/animationiteration). Context info: animationName[, elapsedTime]
* <span style="font-weight:bold; color:blue">SVG:</span> TimeEvent (type: beginEvent/endEvent/repeatEvent). Context info: repeat iteration.<br/>

Manipulating timing

* <span style="font-weight:bold; color:orange">CSS:</span> Interfaces for manipulating keyframe rules
* <span style="font-weight:bold; color:blue">SVG:</span> Standard DOM interfaces (plus above-mentioned animation-specific methods)

'''Summary:''' DOM interfaces are fairly different. SVG lacks per-animation pause control but otherwise offers more control. The difference in event names is unfortunate.

===DOM modifications===

* <span style="font-weight:bold; color:orange">CSS:</span> The values used for the keyframes and animation properties are snapshotted at the time the animation starts.<br/>
* <span style="font-weight:bold; color:blue">SVG:</span> Not specified. (Dynamic changes allowed?)

===Other fundamental differences===

Approach to script

* <span style="font-weight:bold;color:orange">CSS:</span> assumes script is possible&mdash;e.g. restarting requires script
* <span style="font-weight:bold;color:blue">SVG:</span> tries to remain declarative. A significant use case for SVG animation is ''SVG assets'' (SVG backgrounds, fonts, cursors, favicons, <img> etc.) where script is not available

==Harmonisation==

Danger of creating a confusing platform of overlapping techologies that are subtlely different and incompatible.

===Possible approaches===

# Drop SVG Animation altogether and extend CSS Animations
# Merge the two into one master Web Animations spec with two syntaxes: CSS and XML
# Leave them as two separate technologies but make them play well together
#* Assign clear roles to each so web developers can easily judge when to use which
#* Make overlapping areas overlap properly (e.g. align syntax, interpolation rules)
#* Where either technology is suitable make them interchangeable

(The following analysis was helped hugely by Cameron's notes: http://www.w3.org/Graphics/SVG/WG/wiki/Talk:F2F/Auckland_2011/CSS_Animation)

===Option 1: Drop SVG Animation altogether and extend CSS Animations===

Following are some of the features that SVG currently offers that CSS does not. We needn't necessarily import all of them into CSS but this gives some idea of the scale of the task if we want to provide roughly equivalent functionality.

* Combining with the underlying value: e.g. applying supplemental transformations to an element that already has a transform applied.
** Also includes special types of animation like to-animation and by-animation
* Combining independent animations of the same property: e.g. a 'swell' animation and 'spin' animation applying at once.
* Animation along a path
** Including "paced" animation which is most useful in this context
* Begin/End in response to arbitrary events, other animations, etc.
* End/Restart without script
* Scheduled timing (e.g. begin="2s; 5s")
** Adding this to CSS means determining if and when animations can automatically restart (SVG has <code>restart="never|whenNotActive|always"</code>)
* Synchronisation between animations
** Means defining what sort of cyclic references are permitted and how they should be broken
* Cumulative repeats
* Fill behaviour (i.e. continuing to affect animated value after animation has finished)
* Document-level pause control
* Document-level seeking

===Option 2: Merge the two into one master Web Animations spec with two syntaxes===

Based on the above analysis, I think there are fundamental differences that make merging difficult. It would likely involve dropping compatibility with one technology or the other. (If we drop compatibility with SVG then it's basically Option 1.)

'''UPDATE:''' On further consideration, I'm not sure it's impossible. It will probably involve some backwards-incompatibility but it's possible that such incompatibility is only minor.

===Option 3: Make SVG Animation and CSS Animation play well together===

====Assign clear roles to each so web developers know when to use each====

* For example, ''CSS Animation as a simplified SVG Animation''. Ensure the functionality of CSS Animation is a subset of SVG Animation
** &rarr; if you find yourself hitting the wall with CSS, time to consider SVG
** Means adding to SVG anything missing that's in CSS: e.g. reversing, re-usable animations
* Are there other ways of separating their roles?

====Make overlapping areas overlap properly====

=====Align syntax=====

* Add CSS' <code>transition/animation-timing-function</code> keywords to SVG
** Also involves allowing mixing timing functions within the one animation (currently only one <code>calcMode</code> per animation)
* Rename / alias events? Standardise on which one? TimeEvent vs AnimationEvent? beginEvent vs animationstart?
** [http://www.w3.org/Graphics/SVG/WG/wiki/Talk:F2F/Auckland_2011/CSS_Animation#Events Cameron has some suggestions here]

=====Make interpolation consistent=====

* Integer rounding
* Color space interpolation&mdash;ok to leave CSS as just sRGB? Add HSL to SVG?
** CSS Transitions needs to specify if interpolation is in premultiplied space or non-premultiplied and SVG should do likewise if it ever does RGBA colors.
* In future, SVG's <code><animate></code> should be able to target a transform list (obsoleting <code><animateTransform></code> on the way) and should try to align with [http://www.w3.org/TR/css3-2d-transforms/#animation the animation definitions in CSS Transforms] for this.
* Cameron also notes that we it would be good to have definitions for how '''all''' CSS properties animate even if they're not interpolatable, e.g. fallback to discrete animation. [http://www.w3.org/Graphics/SVG/WG/wiki/Talk:F2F/Auckland_2011/CSS_Animation#Unifying_interpolation]

====Where either technology is suitable make them interchangeable====

=====CSS animating SVG &mdash; Allow CSS to animate SVG attributes too?=====

* Cameron has pointed out some of the problems with
** Promoting SVG attributes to properties
** Introducing new properties
** See: http://www.w3.org/Graphics/SVG/WG/wiki/Talk:F2F/Auckland_2011/CSS_Animation#Using_CSS_Transitions.2FAnimations_with_current_SVG_attributes
* So in Auckland we proposed going with the <code>attr()</code> syntax to allow CSS Animations to target SVG attributes.
** There was some outstanding concern about whether this syntax could appear on the LHS (particularly re CSS Transitions)
** See: http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0199.html
* Would the animation result be stored in the animVal? i.e. acts as an additional animation of lowest priority (applies before SVG Animations)
** See also Cameron's notes about this: http://www.w3.org/Graphics/SVG/WG/wiki/Talk:F2F/Auckland_2011/CSS_Animation#Using_CSS_Transitions.2FAnimations_with_current_SVG_attributes

=====SVG animating CSS=====

* Allow SVG animation to target non-SVG content?
** May be necessary if we decide that CSS Animation is a subset of SVG Animation
** Might mean adding further definitions for what addition means for various CSS types?

=====Allow SVG animations to be used as an <code>animation-name</code>=====

* This will require reworking SVG Animations to make them re-usable which is already proposed.
** See: http://www.w3.org/Graphics/SVG/WG/wiki/Talk:F2F/Auckland_2011/CSS_Animation#Named_animations and http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements#Wanted_feature:_re-use_animations
* Does an animation applied in this way still alter SVG animVals in the DOM? But is lowest priority?
* Cameron has put forward some concrete suggestions about the effect of applying CSS Animation properties to SVG Animations: http://www.w3.org/Graphics/SVG/WG/wiki/Talk:F2F/Auckland_2011/CSS_Animation#Applying_the_CSS_Animation_properties_to_SVG_Animations

=====Synchronisation between the two?=====

* Allow CSS Animation names to appear in SVG syncbase timing specifications?
* The other direction (triggering CSS Animations from SVG) should already be possible in a limited fashion: Use a <code><set></code> animation to change a <code>class</code> attribute. However, this won't give proper behaviour in the case of a seek.