Re: [css3-transforms] ... to-animation

Dirk Schulze:
>
> > 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.
>

What is written in SVG tiny 1.2 about this (and copied to SVG 1.1.2), 
was just a result from the issue, that for unknown reasons the type matrix 
was not animatable and there was not much motivation to clarify the
situation, this was simply delayed to the next version.
However with the CSS draft the matrix type becomes animatable and
this can be considered as a new version/variant for SVG transform,
therefore to avoid the situation, that this is forgotten and undefined
again, we should clarify it now.
And if we look into the definition of to-animation in SMIL 2/3, this
finally is a clarification of the original animation recommendation, 
current versions of SVG still refer to - the normative behaviour of
to-animations is not defined to be additive at any time, therefore 
no conflict with post-multiplication of SVG animateTransform.

Because the CSS draft assumes anyway, that it is reasonable that
the viewer should have a capability to analyse the structure of
two consecutive values in a values list, it should be reasonable
as well, that it can analyse whether the underlying value of a
to-animation is of the same type as the to-value is.
I think, for SVG1.0 - 1.2 it was not considered, that a viewer
needs have such a capability, therefore no surprise, that
trouble occured here, what is solvable now with advanced
capabilities.

Rule 1:
If it is the same type, simply animate between the underlying
value and the to-value with the type that is noted for to-value
using the usual SMIL method for to-animations.

This behaviour can be observed anyway in current viewers
with a meaningful interpretation of to-animations, therefore
it seems reasonable, that a viewer can do this.
And I think, it will cover already a lot of ideas, authors
have in mind for to-animations.

Rule 2:
If they are not of the same type, convert both to matrices
and interpolate between the matrices. The type for the
to-value is only used to convert the value to a matrix.
Use for these matrices the usual SMIL method for to-animations.

This is more or less only a fallback for this more
problematic case, maybe not really important for
most authors anyway.
Obviously this has limitations for authors, for example
if the to-value is of type rotate, there will be not 
difference between values like -180, 180, 540.
But at least one gets the intended effect for
continuous to-animation, a smooth change from
the underlying value to the to-value.
I think, using decompostion will not result in 
something much better, especially because
the inversion problem may occur again.


Minor problem one has to face (as an author) with this:
If a lower priority animation is ended before
the end of the to-animation, and fill of this is not
freeze, a new underlying value may appear,
that has another type. In this situation of
course the viewer has to reconsider, whether
rule 1 or 2 has to be used. But typically this
is not really a big additional problem, because
typically this end without freeze will result
anyway in a discontinuity and the author will
not get a smooth change anyway.





Olaf

Received on Monday, 4 June 2012 13:02:58 UTC