- From: Daniel Holbert <dholbert@mozilla.com>
- Date: Mon, 20 Jul 2009 15:49:14 -0700
- 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 UTC