Re: Inheritance during SVG Animation of CSS properties -- should "base value" incorporate ancestors' animation effects?

Hi Daniel,

	I agree with your proposed answer(s), so +1 from me.
But there are more knowledgeable people w.r.t SMIL on the
group than me, so it should definitely be discussed, and
it would be good to get implementors involved who may have
already hit this sort of issue.

	A test-case for the full test-suite would be good too.

Alex

--Original Message--:
>Hi www-svg,
>
>Today, jwatt & I were speaking about the issues raised in this thread 
>from last year (links to original posts are at end of this email), and 
>he suggested that I bring this back up for possible discussion on a 
>teleconference, to hopefully establish a consensus of some sort.  Could 
>we discuss this at some point during an upcoming SVG call?
>
>To paraphrase the basic question from the thread:
>  THE SETUP:
>  - Suppose a given property is being animated on a (parent) node.
>  - Suppose there's a child node that has the value "inherit" for this 
>same property. (so, it's inheriting the parent's animated value, since 
>SVG 1.1 19.2.9 says that animated values inherit where applicable)
>  - Now, suppose we begin a "by" animation that targets our property on 
>the child node, e.g.
>     <animate by="[amount] dur="1s".../>
>
>  MY QUESTION: What should be used as the "base value" for this 
>animation on the child node?  The actual underlying value is "inherit", 
>but what should that evaluate to, when we place it at the base of the 
>animation sandwich to compose the child's "by-animation"?  Should we use 
>the parent's animated value, or the parent's underlying non-animated value?
>
>  MY PROPOSED ANSWER: The most sensible thing is to use the parent's 
>*animated* value, since that's what we'll be using on the child up until 
>the moment the "by-animation" begins, and I feel like the idea of a 
>"by-animation" is to smoothly animate away from the value that was 
>showing before the animation started.  (If we instead used the parent's 
>non-animated value, then that could trigger a huge jump at the moment 
>the child's "by-animation" begins.)
>
>This problem is (slightly) more general than this, though -- in 
>particular, we hit the same basic question with the "currentColor" 
>value, with no inheritance at all.  The situation for this is as 
>follows: if we animate the "color" attribute on an element that has e.g. 
>style="fill: currentColor", and then we begin a "by" animation on the 
>"fill" property, should the "color" animation feed into the base value 
>of the "fill" animation?  (I'd say "yes".)
>
>So, to clarify this issue generally, I propose that the SVG spec be 
>amended/clarified to state something like this:
>
>========
>If an attribute is being animated and its base value* could be 
>influenced by another attribute's animated value**, then during each 
>animation sample, the browser should compose animations on the 
>influencing attribute _before_ composing animations on the 
>potentially-influenced attribute.***
>
>* e.g. 'inherit' or 'currentColor' on a particular element.
>** e.g. the parent-element's value for the same property, or the value 
>of 'color' property on the same element.
>*** e.g. we should compose any given property on ancestors before 
>composing that property on their children, and compose animations on the 
>'color' property on a given node before composing color-valued 
>properties on that node.
>========
>
>I'm asking for clarification on this because this behavior isn't 
>well-defined in any spec right now.  SVG 1.1 Section 19.2.9 gives meager 
>support to my position by simply affirming that animated values can be 
>inherited, but it doesn't mention at all how the inherited values should 
>interact with animations on children. (and it of course it doesn't 
>mention the analogous color/currentColor issue).   On the other hand, 
>SMIL3 specifies an action that goes against my suggested behavior.  It 
>says we should clear the whole override stylesheet before looking up the 
>base value of any CSS property. (which would hide any animated values 
>and prevent them from being inherited as base values for other 
>animations) However, SMIL3 never even mentions the word "inherit", so it 
>might just be that it doesn't consider inheritance issues at all.
>
>Here are my links to my posts on this from last year, with a bit more 
>details & actual spec references:
>  * My initial post:
>      http://lists.w3.org/Archives/Public/www-svg/2009Jul/0037.html
>  * Cameron [largely agreeing w/ me & bringing up SMIL 3]:
>      http://lists.w3.org/Archives/Public/www-svg/2009Jul/0052.html
>  * Me [lamenting the trouble that SMIL 3's language causes]:
>     http://lists.w3.org/Archives/Public/www-svg/2009Aug/0008.html
>
>(Sorry for the large post -- this is a complex & subtle issue, so I want 
>to try to be precise & minimize hand-waving.)
>
>Thanks!
>~Daniel
>
>

Received on Wednesday, 9 June 2010 02:25:02 UTC