W3C home > Mailing lists > Public > www-svg@w3.org > July 2009

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

From: Daniel Holbert <dholbert@mozilla.com>
Date: Mon, 20 Jul 2009 15:49:14 -0700
Message-ID: <4A64F46A.6000900@mozilla.com>
To: www-svg@w3.org
CC: Brian Birtles <birtles@gmail.com>, Robert O'Callahan <roc@ocallahan.org>
[I originally sent this to www-style, but it's probably more appropriate
for www-svg -- hence, mailing to www-svg now]

Hi www-svg,

I'm working on Mozilla's implementation of SVG Animation (using SMIL)
for CSS properties, and I have a clarification question about how that
should interact with inheritance of (SMIL-)animated CSS properties.

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?

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?

(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.

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.

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)
 (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.

  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.

[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'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.

  However, this is just my interpretation, and I don't think it's
explicitly stated in the spec.
Received on Monday, 20 July 2009 22:49:55 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:42 GMT