RE: [SMIL21] Animating CSS properties

As I recall, the assumption is that the compositor (computing the final
values for animation) must clear the override stylesheet, get the
computedStyle and then set the override. The intent is that we do not
touch the OM values corresponding to authored specifications in author
stylesheets. Script may affect these, which is why the implementation
must get the computed style each time the animation is sampled and
updated.

Note that the discussion referenced is informative - implementations may
choose somewhat more efficient mechanisms for implementing this. If you
are interested, there are several implementations of the SMIL animation
mechanisms in the context of SVG implementations for Mozilla, not to
mention the XHTML+SMIL (branded as HTML+TIME)implementation in IE 5.5
(and later) for windows.

Patrick

-----Original Message-----
From: www-smil-request@w3.org [mailto:www-smil-request@w3.org] On Behalf
Of Cameron McCormack
Sent: Tuesday, February 07, 2006 5:52 PM
To: www-smil@w3.org
Subject: [SMIL21] Animating CSS properties



Hi.

SMIL 2.1 says[1] this about animating CSS properties:

  When animation is applied to CSS properties of a particular element,
  the base value to be animated is read using the (readonly)
  getComputedStyle() method on that element. The values produced by the
  animation are written into an override stylesheet for that element,
  which may be obtained using the getOverrideStyle() method.

  [...]

  Although animation does not manipulate the OM values, the document
  display must reflect changes to the OM values. Host languages can
  support script languages that can manipulate attribute values directly
  in the OM. If an animation is active or frozen while a change to the
  OM value is made, the behavior is dependent upon whether the animation
  is defined to be additive or not, as follows: (see also the section
  Additive animation). 

There is a problem here in that animation does manipulate the OM values;
the override style sheet is part of the CSS OM.  Because:

  * CSS animations are effected by modifying the override style sheet,

  * the base value is obtained by calling getComputedStyle(),

  * getComputedStyle() takes into account the override style sheet, and

  * animations should take into account changes to the base value,

additive CSS animations that use the base value are going to be somewhat
counter-intuitive.  For example, take this SVG snippet:

  <rect width="100" height="100" stroke-width="1">
    <animate attributeName="stroke-width" attributeType="CSS"
             begin="0s" dur="5s" from="0" to="10" additive="sum"/>
  </rect>

If the animation is sampled at 1s intervals, this would be the result:

  Time  Base value  Animation value  Final animated value
  ----  ----------  ---------------  --------------------
  0s    1           0                1
  1s    1           2                3
  2s    3           4                7
  3s    7           6                13
  4s    13          8                21

since the base value now (erroneously) reflects the animated value.
Three solutions I can think of:

  * the animated values should not be written into the override style
    sheet, but instead into some "hidden" place that the cascade also
    takes into account,

  * the base value should not be derived from the result of
    getComputedStyle(), but rather what getComputedStyle() would have
    returned if there were no corresponding value in the override style
    sheet, or

  * do not allow animation of CSS properties to reflect changes to the
    base value while they are running.

Thoughts?

Thanks,

Cameron

[1]
http://www.w3.org/TR/2005/REC-SMIL2-20051213/animation.html#animationNS-
AnimationSandwichModel

-- 
 Cameron McCormack			ICQ: 26955922
 cam (at) mcc.id.au			MSN: cam (at) mcc.id.au
 http://mcc.id.au/			JBR: heycam (at) jabber.org

Received on Wednesday, 8 February 2006 06:53:29 UTC