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

On Wednesday, June 9, 2010, 2:38:35 AM, Daniel wrote:


DH>   MY QUESTION: What should be used as the "base value" for this 
DH> animation on the child node?  The actual underlying value is "inherit",
DH> but what should that evaluate to, when we place it at the base of the 
DH> animation sandwich to compose the child's "by-animation"?  Should we use
DH> the parent's animated value, or the parent's underlying non-animated value?

DH>   MY PROPOSED ANSWER: The most sensible thing is to use the parent's 
DH> *animated* value, 

Yes.

DH> This problem is (slightly) more general than this, though -- in 
DH> particular, we hit the same basic question with the "currentColor" 
DH> value, with no inheritance at all.  The situation for this is as 
DH> follows: if we animate the "color" attribute on an element that has e.g.
DH> style="fill: currentColor", and then we begin a "by" animation on the 
DH> "fill" property, should the "color" animation feed into the base value
DH> of the "fill" animation?  (I'd say "yes".)

Yes again.

The SVG 1.1SE spec has the same wording as the original SVG 1.1 spec here, and is not as clear as it should be:

currentColor
    Indicates that painting is done using the color specified by the ‘color’ property. This mechanism is provided to facilitate sharing of color attributes between parent grammars such as other (non-SVG) XML. This mechanism allows you to define a style in your HTML which sets the ‘color’ property and then pass that style to the SVG user agent so that your SVG text will draw in the same color.
http://dev.w3.org/SVG/profiles/1.1F2/publish/painting.html#SpecifyingPaint

SVG Tiny 1.2 has better wording, in the first sentence:

currentColor
    Indicates that painting shall be done using the color specified by the current animated value of the 'color' property. This mechanism is provided to facilitate sharing of color attributes between parent grammars such as other (non-SVG) XML. This mechanism allows you to define a style in your HTML which sets the 'color' property and then pass that style to the SVG user agent so that your SVG text will draw in the same color. 


So for currentColor, I propose to back port the "current animated value of the 'color' property" to 1.1SE.

DH> So, to clarify this issue generally, I propose that the SVG spec be 
DH> amended/clarified to state something like this:

DH> ========
DH> If an attribute is being animated and its base value* could be 
DH> influenced by another attribute's animated value**, then during each 
DH> animation sample, the browser should compose animations on the 
DH> influencing attribute _before_ composing animations on the 
DH> potentially-influenced attribute.***

That looks like good wording to me (modulo your correction later in the thread).

DH> * e.g. 'inherit' or 'currentColor' on a particular element.
DH> ** e.g. the parent-element's value for the same property, or the value
DH> of 'color' property on the same element.
DH> *** e.g. we should compose any given property on ancestors before 
DH> composing that property on their children, and compose animations on the
DH> 'color' property on a given node before composing color-valued 
DH> properties on that node.
DH> ========

DH> I'm asking for clarification on this because this behavior isn't 
DH> well-defined in any spec right now.  SVG 1.1 Section 19.2.9 gives meager
DH> support to my position by simply affirming that animated values can be
DH> inherited, but it doesn't mention at all how the inherited values should
DH> interact with animations on children.

It doesn't and should, I agree
 
DH>  (and it of course it doesn't 
DH> mention the analogous color/currentColor issue).

Although I think the wording in the SVG Tiny 1.2 Rec covers this, so could be used in 1.1SE as well.

DH>    On the other hand, 
DH> SMIL3 specifies an action that goes against my suggested behavior.  It
DH> says we should clear the whole override stylesheet before looking up the
DH> base value of any CSS property.

It looks to me as if they were thinking only of discrete properties which do not depend on the value of any other property.

DH>  (which would hide any animated values 
DH> and prevent them from being inherited as base values for other 
DH> animations) However, SMIL3 never even mentions the word "inherit", so it
DH> might just be that it doesn't consider inheritance issues at all.

DH> Here are my links to my posts on this from last year, with a bit more 
DH> details & actual spec references:
DH>   * My initial post:
DH>       http://lists.w3.org/Archives/Public/www-svg/2009Jul/0037.html
DH>   * Cameron [largely agreeing w/ me & bringing up SMIL 3]:
DH>       http://lists.w3.org/Archives/Public/www-svg/2009Jul/0052.html
DH>   * Me [lamenting the trouble that SMIL 3's language causes]:
DH>      http://lists.w3.org/Archives/Public/www-svg/2009Aug/0008.html

DH> (Sorry for the large post -- this is a complex & subtle issue, so I want
DH> to try to be precise & minimize hand-waving.)

No apologies necessary, the precision and detail is appreciated.


-- 
 Chris Lilley                    mailto:chris@w3.org
 Technical Director, Interaction Domain
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Wednesday, 9 June 2010 11:53:02 UTC