by‑animation and scale transformations

One area of SMIL Animation that seems to be unclear is the underlying value to be used when animating scale, especially for by‑animations.

SMILANIM 3.2.2 says that by‑animation is:

simple animation in which the animation function is defined to offset the underlying value for the attribute, using a delta that varies over the course of the simple duration, starting from a delta of 0 and ending with the delta specified with the by attribute.

I’m pretty sure that the underlying value of scale when it’s not otherwise defined is 1. I think this fits with the discussion on www-svg (but just to be sure I’ve posted my query). It certainly makes sense if you assume that an element without a transform specified can be considered to have a transform that corresponds to the identitfy matrix where the scale is 1 (for both x and y).

Now if by represents a delta then by="1" means to ADD to the scale factor 1. So a by‑animation of by="1" operating on an element without any transform specified should animate from scale=“1” to scale=“2”.

Here is a test case based on this understanding:

by‑animation for scale animations Tests behaviour of animating scale using animateTransform. The black circle is the starting point of the animation, and the red circle is the end point. by="1" from="0" by="1" from="1" by="1" to="1" to="2"

UPDATE: See Dr. Hoffmann’s explanation below. A different understanding to mine has been adopted for the SVG Tiny 1.2 Test Suite. This understanding adopts an underlying value of scale(0 0). Here is an updated test case applying this understanding:

by‑animation for scale animations Tests behaviour of animating scale using animateTransform. The black circle is the starting point of the animation, and the red circle is the end point. by="1" from="0" by="1" from="1" by="1" to="1" to="2"



The underlying values is always somehow defined, therefore there is no need to guess one. Especially for animateTransform the underlying value is related to lower priority animations and the complete value of the transform attribute. This can only be assumed to be the identity transform, if there is neither a lower priority animation nor a transform attribute. And this does not depend on the question, which type of animation is currently used. Because this is a complex entity, additive animations have to be postmultiplied and they are not somehow combined with only a notation of one type like ‘transform’, ‘rotate’, ‘scale’, ‘skewX’, ‘skewY’. ‘matrix’ can be an underlying value too, by the way. In SVGT1.2 even a constrained transformation can be an underlying value.

And by-animations do not start with the underlying value, they are only always additive, what is a difference.

The by-animation itself is equivalent to a values animation. With some pseudocode, if A is the value of the by attribute it is equivalent to value=“0;A” additive=“sum”. Furthermore, this animation type is only defined, if the attribute can be animated additive at all (else it has no effect). As without animation, the additive or cumulative effect of transformations can always be tested with nested groups. Each group has only one transform type, respectively animateTransform, the innermost element is the rendered object. This nested group approach has to result always in the same effect as to postmultiply something to a combination of animateTransforms and transform values.

Especially for the transform type scale one can have values as A,B or only A, with A and B numbers.

If we have by=“7” it is simply equivalent to values=“0;7” additive=“sum”. This is everything one has to check, to ensure, that by-animations are implemented correctly. If wie have by=“-2,3” it is simply equivalent to values=“0,0;-2,3” additive=“sum” and this is the onyl thing, one has to check. There is no need to check some arbitrary philosophical assumptions on one might be nice under other circumstances or in another universe. This is simply, what is defined as SMIL animation. And to avoid further long philosophical discussions about the question, what the symbol ‘0’ might be, in SMIL3 it is especially clarified, that it is the neutral element of addition and nothing else. For a list of numbers this is related always to a list of zeros. For colors it is related to #000 and not to ‘none’ or ‘transparent’ or whatever might be funny or interesting under different circumstances.


Oh ok, now I understand what you mean by a neutral value. I agree that what you say makes sense from an implementation point of view. Indeed, this is the way I have implemented it.

But from an author’s point of view the paragraph I quoted from SMILANIM contradicts this. It refers to a delta from the underlying value which we both agree, in the absence of lower-priority animations, or other settings, is 1 for scale. So from an author’s point of view, by=“1” should be a delta from 1.

So can we agree that the SMILANIM specification is contradictory at this point or at least ambiguous? It would be better if the quoted paragraph was replaced with the value=“0;by” additive=“sum” explanation.


The old SMIL animation recommendation is plurivalent in several points. For SMIL animation itself as defined by SMIL this is in most cases no problem, but when animateTransform was introduced in SVG (this is not SMIL), things got more complicated. However, most plurivalences are already avoided in SMIL 2 and 3, therefore it is typically more useful to start with SMIL 3 and to look into SMIL2 for SVGT1.2 if there are any incompatibilities and to look into the SMIL animation recommendation for SVG1.1 for the same reason. In most case the more precise normative definitions in SMIL 2 and 3 only clarify something, therefore they are not incompatible with the old SMIL animation recommendation.

The authors point of view can be different for different authors, if someone needs a continuous cumulative animation, it is certainly contraproductive to start with 1 instead of 0 either ;o)

Leave a reply

Most markdown like **bold** and _italic_ is supported.

Never shown. Only used for looking up your gravatar.