- From: Patrick Schmitz <cogit@ludicrum.org>
- Date: Tue, 7 Feb 2006 22:53:52 -0800
- To: "'Cameron McCormack'" <cam-www-smil@aka.mcc.id.au>, <www-smil@w3.org>
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