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

Dirk Schulze:

...

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

Of course. Therefore if a string appears as a value 
without further explanation, calcMode discrete has to used as default. 

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

I don't think, one has to differ.
SMIL/SVG talks about values and defines from-to, from-by and by
animations only to be equivalent to specific values animations.
http://www.w3.org/TR/SMIL3/smil-animation.html#animationNS-SpecifyingAnimationFunction
http://www.w3.org/TR/SMIL3/smil-animation.html#AnimationNS-FromToBy

Of course, by animation requires additive behaviour and from-by needs 
values that have an addition operation defined.

Only for to-animations there is a specific behaviour defined.

> Even SMIL animations does not differ on further 
> definitions for e.g calcMode and just uses 'from-to'. 

No, as mentioned calcMode cares in general about interpolation between
values from a list, not just from-to. Obviously one has to analyse the
complete list at once to get the default calcMode behaviour right.
But because between all transform values following section 15 one can
interpolate somehow if required, a values list does not cause more
complications (different from for example fill and stroke with possible
paint servers, implicating only discrete behaviour).

> Section 15 
> "Transitions and Animations between Transform Values"[4] is not different
> to SMIL animations here.

Well it is, because it talks only about from-to animation - or at least
the words are chosen in such a way, that this interpretation takes place.
Because this is only a small subset of possible notations, formally this
means currently, that this section is not necessarily applicable for
from-by, by and values animations (to animation is more complex, 
maybe better not to discuss this here now - because the underlying
value may change, this can result in interesting specific effects,
for example following section 15 one might have to change the method
from 'simple' to 'unmatrix' or vice versa within the animation - but there
was not even an agreement to clarify to-animateTransform for SVG 1.1.1).
The solution is just a minor change in wording (avoiding the attribute
representing words from and to), if one talks in general about interpolation
between two successive animation values as SMIL does, this will avoid 
any misunderstanding.
I think, CSS animation can have more than a from and a to value
as well - therefore the irritation may apply for this as well.
And obviously for a longer list 15 should indicate, if the 
method 'simple' or 'unmatrix' has to be selected once by analysing
the complete list or for every current pair of values separately.
Maybe the word 'keyframe' indicates the second option, not sure,
if I understand this correctly, because the draft does not define what
a keyframe is (related to SVG/SMIL animations, I think, in the
draft about CSS animation this word is defined, but has no formal
relation to SVG/SMIL animations - and it would be only confusing
to require reading drafts about CSS animation to get 
SVG/SMIL animation about transform values right - therefore
if 15 is intended to be applicable for both types of animation, 
a few words need to be chosen more carefully to avoid 
misunderstandings).

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

If you need, I can try to propose something, currently I only
mention, that a value like 'scale(3)' is a string, and therefore
does not belong to types, which are allowed for additive behaviour.
I think in doubt one has to say explicitly here, that the numerical
values respectively matrices can be extracted in the same way
as for animateTransform and that additive behaviour is considered
to be the same as for animateTransform (postmultiplicative).

> Even if you use strings for 
> the 'values' attribute, they get parsed to specific property values, in our
> case as <transform-list>. 

That you can parse it, is currently not really important, following the
mentioned SVG section, only the type matters and because such strings are
currently not mentioned in the list, this simply means, this type is something
else and is therefore not additive. Because CSS transform is an extension,
it should be no problem to define here, that additive behaviour is possible
in the same way as for animateTransform, postmultiplication of the resulting
matrix.

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

This is no problem, because such types as <length> are mentioned in the
list of additive behaviour.
For example path d attribute values are not mentioned as well, therefore
these are strings as well and they are not additive.
A few other properties or attributes mention as well explictly, that they
are not additive - should be therefore no problem to mention as
well the opposite for another property or attribute, if required.

> That doesn't mean that you 
> can't use calcMode="discrete".

How is this related? Of course one can always use at least discrete
behaviour, but this is not related to additive behaviour at all.
Maybe I should have separated the comment in three emails,
one about interpolations issues and one about additive behaviour,
one about paced animation ;o)

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

This does not contain any information about additive behaviour.
I cannot understand how this can clarify, if it does not mention
additive behaviour at all. Basically it introduces new value types
like 'scale(3)', currently not available for additive behaviour.

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

For matrices one can calculate an absolute value of the determinant 
or something like this, but I'm pretty sure to use this, this will not
result in a paced animation, just in arbitrary behaviour.
Therefore, if you end up with a matrix, you can surely forget about
paced behaviour.
For example for rotation arond a fixed center/axis, it is no problem to
have paced behaviour, if one determines distances between
the angles. If you calculate the matrices, the chance is lost and
there is no meaningful distance function anymore to calculate
the paced behaviour.

If you have for example two translation values, a meaningful
distance function is the Euclidian distance, nothing else.
For scale the same. 
But if you animate from a rotate value to a translation value
with animate for example, of course no paced behaviour is 
possible, even worse with distortion due to skew or 3D transforms.
animateTransform has always a defined type of transformation,
therefore for such a type sometimes one can define paced
behaviour.
For the animate type typically not - or one has to restrict
this on cases, where the type does not change for the
complete values list, this means, that there is no decomposition
for the complete active duration. And of course, if each value
consists of more than one type, even if this is the same list
for each value, there will be typically no paced behaviour anymore.

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

It depends - if SVG 2 includes this extension and supersedes it again,
why not, but then the extension is not applicable for the missing 
features/clarification before SVG 2 becomes a recommendation
an outdates the older CSS transform text.
And you now about the difficulties, if some implementers have
already some arbitrary interpretation of undefined things
or even a wrong interpretation of defined things in their
programs, to fix this again to something meaningful ;o)

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

This means, the current SVG rules apply, therefore paced animation
for scalar values and no paced animation for scale3d and translate3d.
Others like matrix, matrix3d etc have no meaningful paced behaviour
anyway, therefore ok that the current rule applies.
I think, only a change for scale3d and translate3d might help.

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

It says:
'Distance is defined only for scalar types (such as <length>), colors and the 
subset of transformation types'
therefore no problem, if an extension defines new scalar types that are
transformation types as well - you need no specific additional formula
for every new scalar.

>
> 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]

This is not completely the same thing.
Even if you interpolate for example between matrix, matrix and matrix, 
there will be no meaningful distance function to get a paced behaviour.
I think, the same applies for rotate3d if the direction of the rotation 
axis changes - this is similar to a change of the rotation center of
rotate.

> 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 Friday, 27 April 2012 10:32:01 UTC