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

Hi Olaf,

On Apr 27, 2012, at 3:31 AM, Dr. Olaf Hoffmann wrote:

> 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.
IIRC, you saw a problem with not defining the additive behavior on CSS3 Transforms. Could you look at the new section "The 'animate' and 'set' element" [1] please? Is it sufficient? Am I missing something?

>
>> 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.
I used the same definition of additive behavior on 'animate' and 'set' as for 'animateTransform'. However, there is a difference. For 'animateTransform', all animated transforms get post-multiplied and then this result gets post-multiplied to the base value. The behavior for 'animate' and 'set' is like for all other values now. So base value gets 'replaced' by the animation value on rendering. No post multiplication to base value, with the exception of additive="sum".

>
> Only for to-animations there is a specific behaviour defined.
To animations are not supported on CSS Transforms, the same like for 'animateTransform'. If you have a good suggestion how to animations are supposed to work. I am happy to define it.

>
>> 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 behavior).
For paced animations I would agree. The definition on error handling for SVG says that it should get animated since the first error. E.g for values="translate(20) ; translate(100) ; translate(invalid)" calcMode="linear" you would see an animation from 20 to 100. See SVG 1.1 error processing: "If the document has animations, the animations shall stop at the point at which an error is encountered and the visual presentation of the document shall reflect the animated status of the document at the point the error was encountered."

>
>> 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).
Yes, would be great. Like written before, it is undefined at the moment.

> 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.
It is not necessary IMO: values="translate(20px) ; translate(100px) ; rotate(45deg)"

For the first part of the animation, you can use the transform function interpolation [2]

> 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).
There were concerns raised about this wording before. I tried to change the wording, so that it is not specific to any kind of animation, but describes interpolation between two transform function lists. See [3]. Would be happy to get your opinion about the change.

>
>>
>>> 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).
I hope that the definition on [1] is more explicit now.

>
>> 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)
Actually, I think this is a good idea. This thread is really long now :)

>
>>
>> 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.
The SVG WG agreed to let paced animation undefined for CSS3 Transforms. The ED already does so [1]. At the moment I am unsure what would be the best definition for paced animations. On the one hand I would like to have at least the same possibly for paced interpolations like on animateTransform, on the other hand I am unsure if the spec should  explicitly deny specific transform-list animations to be paced. Or better how should a transform-list look like to allow paced animations. Since CSS3 Transforms interpolates each function pair separately as long as the transforms follow the third (and second) rule of [2], I don't see a reason not to allow paced animations for these kind of interpolation. Like discussed above, the implementation must verify the complete animation steps to verify that the third rule is always true. But then again, like you said in another post, even rotate with three arguments is not allowed together with paced animations. This is something that should be discussed in a new thread.

>
>> 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)
The SVG WG decided not to change behavior on 'animateTransform' on CSS3 Transforms. It should be done in SVG Animation itself. For the moment, animateTransform would just be limited to the defined behavior of SVG 1.1. Which is fine. It will also be discussed if 'animateTransform' gets deprecated.

>
>> 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.
See comment above.

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

>
>>
>> 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.
Do you know where it was discussions previously?

>
>> 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
>
>
>
Greetings,
Dirk

[1] http://dev.w3.org/csswg/css3-transforms/#svg-animate-element
[2] http://dev.w3.org/csswg/css3-transforms/#interpolation-of-transform-functions
[3] http://dev.w3.org/csswg/css3-transforms/#animation

Received on Friday, 1 June 2012 22:58:15 UTC