Re: [css3-transforms] about ‘animate’ and 'animateTransform'

Hi Olaf,

On Apr 26, 2012, at 9:43 AM, Dr. Olaf Hoffmann wrote:

> Hello,
> 
> this is about:
> http://www.w3.org/TR/2012/WD-css3-transforms-20120403/#svg-animate-element
> http://www.w3.org/TR/2012/WD-css3-transforms-20120403/#svg-animateTransform-extension
> 
> The section 7.8.1. allows animation of the transform attribute/property with 
> the SVG/SMIL elements animate and set.
> As far as I understand this for animate the values list will look like this:
> values="scale(3); translate(15 23); skewX(30) skewY(-30); perspective(17)"
> right?
Yes, that is correct.

> 
> Obviously the values are strings.
> Well, ok, because section 15 is referenced, it seems to be ok to interpolate 
> with calcMode linear, spline, not just discrete animation, as the definition
> of calcMode might implicate without these further explanations from 15, right?
It would be the same like for CSS Animations where you can define different keyframes. Every value in the value list is a keyframe. And yes, it would allow different 'calcMode' settings, since we define how to decompose matrices and animate between different transform functions.

> 
> But note that from-to, from-by and by animations are anyway equivalent
> to specific values animations, therefore 15. should better explain
> rules for animation values in general, not only for from-to,
> because the equivalent-rule covers from-to already.
> Without a general explanation obviously for values animations
> the usual SMIL rules apply, this means here calcMode discrete
> for strings. Due to the equivalent-rule then this applies for from-to as
> well. But I think, this is not intended, therefore the text in 15 needs
> to be more general to be applicable.
In general 'calcMode' is defined by SMIL Animations 3.0 as well as SVG Animations [1]. I don't think that we should redefine it in CSS3 Transforms explicitly. Note that 'calcMode' on SMIL animation is similar to 'animation-timing-function'  in CSS Animations [2]. Also I don't share your meaning that we have to differ between values animations, from-to and from-by animations. Even SMIL animations does not differ on further definitions for e.g calcMode and just uses 'from-to'. Section 15 "Transitions and Animations between Transform Values"[4] is not different to SMIL animations here.

> 
> I just wanted to note, that currently 
> http://www.w3.org/TR/SVG/animate.html#AnimationAttributesAndProperties
> explictly notes which attributes are additive and cumulative, such strings
> are not, even if only something like values="scale(3); scale(-3)" is noted.
> This looks different from the same animation with animateTransform.
> Is this intended? If not, there is some text required about additive
> behaviour.
I am not sure if I understand what you propose. Even if you use strings for the 'values' attribute, they get parsed to specific property values, in our case as <transform-list>. That is done everywhere else as well, e.g values="100px; 100cm; 50in" are strings, but get parsed as <length> values for the attributes 'width', 'height' and others. That doesn't mean that you can't use calcMode="discrete".

I agree that the table on the linked spec should be updated to allow the data type <transform-list> on the 'animate' element. But this is clarified by "12.8.1. The SVG ‘animate’ and ‘set’ element"[3] on CSS Transforms at the moment. Please respond if you think this is not sufficient.

> 
> Another issue is, that currently 
> http://www.w3.org/TR/SVG/animate.html#complexDistances
> explains possible types for paced animation.
> Obviously there is no paced animation between strings.
> But for a few transform types this could be defined, some more
> as currently for animateTransform possible - will this be added in
> the future or will this remain excluded for animate animations of
> transform?
That is an interesting question. Since we need to look at each value of type <transform-list> on values on the attribute 'values' (it gets complicated to write a meaningful sentence). I still think that it is possible. First we would have to look if all transforms in <transform-list> are of the same type in the same order. If yes, we can just use the specified behavior[4]. If not, we would need to create a 4x4 matrix of all <transform-list>, decompose these list and use the explanation on http://www.w3.org/TR/SVG/animate.html#complexDistances after that. Note that we would have to update this explanation by the new transform types in CSS Transforms. I think that is an issue that should be addressed on SVG animations and not in this spec. However, It means that we have to look at each component of the transform over time. Everything but "Paced animation and complex types" is already covered by section "12 The 'transform' attribute"[5] and "15. Transitions and Animations between Transform Values"[4] IMO. I think we should raise this for SVG 2.0.

> 
> However for animateTransform it seems to be simpler to allow
> some more paced animations.
> I think, SVG 1.1.1, section19.2.7
> allows already paced animations for scalars like rotateX/Y/Z,
> scaleX/Y/Z, translateX/Y/Z, perspective etc.
I don't think that this sections allows this at the moment. Just for the 2D subset without scaleX, scaleY, translateX and translateY so far.

> However, with some additional text this could be available as well
> for scale3d and maybe translate3d - is it intended to add this?
> Paced animations seems to be excluded for example for
> matrix, matrix3d, rotate3d, because there seems to be no meaningful 
> distance function resulting in a paced animation. 
> For example rotate3d has similar problems as rotate with its three parameters,
> but I think, the parameter values of translate3d can be adjusted in a way, 
> that one can compute a distance, if all values are converted in user units 
> before.
We have to be more clear on animation of transform functions of the same type in the spec. We have an issue on CSS Transforms for that at the moment[6]. So the section of "19.2.7 Paced animation and complex types"[7] might just link to CSS Transforms after the update. We should raise that on the SVG WG. I'd rather not define to much on CSS Transforms.

Thanks for your feedback!

Greetings,
Dirk

[1] http://www.w3.org/TR/SVG/animate.html#ValueAttributes
[2] http://www.w3.org/TR/css3-animations/#animation-timing-function-property
[3] http://dev.w3.org/csswg/css3-transforms/#svg-animate-element
[4] http://dev.w3.org/csswg/css3-transforms/#animation
[5] http://dev.w3.org/csswg/css3-transforms/#svg-transform
[6] https://www.w3.org/Bugs/Public/show_bug.cgi?id=14715
[7] http://www.w3.org/TR/SVG/animate.html#complexDistances

> 
> 
> Olaf
> 
> 
>

Received on Thursday, 26 April 2012 18:06:24 UTC