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

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 00:39:12 UTC