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

Hi Daniel.

Daniel Holbert:
> MY QUESTION: Suppose we're computing the "base value" for an animation
> that targets a particular property on a particular element.  Should that
> "base value" include animations on the element's ancestors?  Or should
> all animation effects be excluded for base-value computation?

My guess, without any sort of spec justification, is that the base value
should be computed with regard to the animated values of ancestors.

> As an example, suppose we're animating the "font-size" property on a <g>
> element, and partway through the animation, a different additive
> "font-size" animation begins on one of that element's children.  Should
> the second animation build off of the inherited *animated* value (which
> will continue changing over time), or should it build off of the
> inherited *un*-animated value?

If the second animation is a percentage value, then I think it should
compute down to a percentage of the ancestor’s animated font size.

> (See "RELATED SECTIONS OF SPEC" below for definitions of terminology)
> 
> I discuss this question a bit in a Mozilla bug 474049, here:
>    https://bugzilla.mozilla.org/show_bug.cgi?id=474049#c64
> and I link to some example SVG documents there.  My interpretation is
> that inherited animation effects *should* be included.  My feeling is
> that "by" and "to" animations (the only animations that actually use the
> base value) are by nature supposed to smoothly animate from the value
> that would be displayed if the animation weren't there.  If we ignore
> inherited animation effects, that would break this behavior, by making
> these animations "snap" back to the un-animated value when they begin.

With this particular example, I think the spec justifies option A.  SMIL
Animation defines the underlying value for a CSS property to be whatever
the computed value of the property would be (see where it mentions
getComputedStyle() in
http://www.w3.org/TR/smil-animation/#AnimationSandwichModel).  (Though
of course you can’t directly use getComputedStyle() if you are writing
the animated values to the override style sheet, unless you want to
unapply the animation first before calling getComputedStyle().)

> I'd appreciate any feedback on whether my interpretation is reasonable.
> Ideally, an eventual clarification/correction in some spec would be
> great, as well.   If anyone knows of a definitive answer for my question
> in an existing spec, please let me know.  Below, I reference & discuss
> several relevant sections of specs -- these provide hints, but no
> definitive answer.

I think it would make a good example in the spec.

> EXISTING IMPLEMENTATIONS DISAGREE
> =================================
> As I noted in https://bugzilla.mozilla.org/show_bug.cgi?id=474049#c64
> I've tested a few implementations, using some testcases linked in that
> bug comment, and they disagree on this issue.
> 
>  (A) Includes inherited animation effects in CSS properties' base value:
>      - Opera v10.00 beta
>      - My latest patch for Mozilla/Firefox (linked on that bug)

Batik too.

>  (B) Excludes inherited animation effects in CSS properties' base value:
>      - WebKit Trunk (r45934)
> 
> RELATED SECTIONS OF SPEC
> ========================
> [1] SMIL Animation section 3.5, "Sandwich Model"
>   * URL: http://www.w3.org/TR/smil-animation/#AnimationSandwichModel
>   * Summary: defines "Base value" for CSS properties, but isn't clear
> about what should go in to it.
>   * More Details/Discussion:
>   This section says that for CSS properties, the base value should be
> read using getComputedStyle(), and that animation effects will later be
> "reflected in a new computed value (and thus, modified presentation)".
> 
>   Clearly, we need to disable some animations before we make the
> getComputedStyle() call, or else our animation effects would feed back
> into their own base value (since they are supposed to be "reflected in
> [the] computed style").  The spec ignores this need to disable
> animations, though, so it's unclear which animations should be disabled
> for this getComputedStyle() call.

Ah I should read the entire mail before I start replying. :-)

SMIL 3 mentions the issue with the override style sheet affecting the
computed value:

  http://www.w3.org/TR/SMIL3/smil-animation.html#animationNS-AnimationSandwichModel

>   If this issue were clarified, it would essentially answer the question
> that I've posed in this email.  That is -- if we're supposed to disable
> all animations before generating the base value, that would effectively
> mean that the "base value" should NOT incorporate ancestors' animation
> effects.  If we're only supposed to disable those animations that
> directly target our element/property, that would effectively mean that
> the "base value" *should* include ancestors' animation effects.

Hmm.  I suppose it does need to be a set of animations, since when
determining the underlying value of font-size on an element, you don’t
want the currently animated font-size-adjust value to be used.  I
suppose for every property we need to know which other properties on the
same element will affect its computed value.  This is a bit messy.

> [2] SVG 1.1 Section 19.2.9, Animation | Inheritance
>   * URL: http://www.w3.org/TR/SVG11/animate.html#Inheritance
>   * Summary: says that animated values are inherited, but doesn't
> explicitly specify how the inherited values interact with animations on
> descendants.
>   * More Details/Discussion:
>   In my opinion, the "spirit" of this section implies that we should
> include inherited animation effects when creating a base value.

I think you’re right, but that section is a bit unclear.

> I'd argue that the inherited animation effects aren't truly being
> "inherited" if they end up being ignored (in favor of the un-animated
> underlying value) whenever a conflicting animation starts up on a
> descendant.

Yeah.

>   However, this is just my interpretation, and I don't think it's
> explicitly stated in the spec.

That section could do with rewording to explain this whole issue.  If
you’d like to propose some replacement text soon there might be enough
time to get it into the Second Edition.

Thanks,

Cameron

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Thursday, 23 July 2009 02:14:49 UTC