One issue that is not spelled out with regards to <animateTransform> is its
interaction with to‑animation.
to‑animation produces a special kind of animation that interacts with its base
value, however it is unclear just what this base value is in SVG 1.1.
Consider the following case (Case 1):
<svg xmlns="http://www.w3.org/2000/svg">
<path d="M-2 50h4v -90h4l -6 -10 -6 10h4z" fill="blue"
transform="rotate(-90)">
<animateTransform attributeName="transform"
type="rotate" to="90" dur="2s" fill="freeze"/>
</path>
</svg>
It’s pretty easy to work out what should happen here. The animation should interpolate from -90 to 90. The base value is that rotation transformation of -90 degrees.
Here’s the result in your browser:
But what happens if the underlying value is more complicated like so (Case 2):
<svg xmlns="http://www.w3.org/2000/svg">
<path d="M-2 50h4v -90h4l -6 -10 -6 10h4z" fill="blue"
transform="rotate(-90) translate(0 50) scale(2)">
<animateTransform attributeName="transform"
type="rotate" to="90" dur="2s" fill="freeze"/>
</path>
</svg>
What’s the base value now? Are you really supposed to pull apart the transform list and try to come up with something that will result in a rotation from -90 to 90 now?
Most implementations say no. Opera and Batik both behave as expected for Case 1. For Case 2, Opera just rotates from 0 to 90 which I believe is correct (there was some discussion of this on www-svg about an identity transform), whilst Batik 1.7 throws NullPointerExceptions.
Here’s the result in your browser:
This is pretty confusing for web authors which is perhaps why in SVG1.2 Tiny they just made it undefined.
The problem is, we cannot (always) have both, the functionality provided by SMIL to get a smooth change from the underlying value to the to-value and to have the specific rule from SVG to postmultiply the animation effect to the underlying value.
If we want to have the functionality of a to-animation as defined in SMIL - what is obiously useful for authors, every other behaviour can be easily covered by other animation types, but not that of a to-animation - we need to animate the matrix. The underlying value can be represented by a matrix and the to-value can be represented as a matrix. After this the interpolation between the matrices (!) can be done as specified in SMIL, leading to a meaningful and useful behaviour. (Note that unforunately the matrix type cannot be animated itself in SVG, but technically there is no problem and the resulting effect is interesting - this can be simulated with a frame based discrete animation for example with an animation of xlink:href of use to exchange the displayed object, precaluated previously for each frame, with about 10-20 frames per second). The requirement of SVG to postmultiply the animation effect causes a problem at least for some situations. For most animations one can simply calculate the inverse of the underlying value and after some recalculations one can get some formula, which expresses the SMIL interpolation as a postmultiplied transformation. However, because not for all possible underlying values the inverse exists, therefore this does only work for most cases, not for all. And all this creates a lot of unneccessary calulations, similar to the formalism introduced to realise a constrained transformation in SVGT1.2 - what has the same problem with the possibly missing inverse.
Because there are no specific restrictions in SVG1.1, this is in general a defined behaviour, as long as the inverse exists (and for other cases one can in general derive the correct behaviour simply by ignoring the requirement to postmultiply ;o)