Re: Some thoughts on css transforms in svg

On 12/03/2010, at 11:36 PM, Dr. Olaf Hoffmann wrote:

> Especially for animation the CSS-draft is 
> pretty incompatible to SVG/SMIL due to this
> decomposition.
> And a SMIL animation is always performed on
> the provides values.

SVG animation does not go into detail about how to calculate the interpolation for a complex type like matrix. I would argue that the decomposition approach in CSS is just as valid as any other.

Also, animateTransform doesn't even support matrix animation - it's always by type (translate, scale, rotate, skewX, skewY).

> This does not fit to the idea
> of the CSS-draft to decompose for example a
> matrix in a larger set of transformations and 
> to animate these. To have this, one needs maybe
> another calcMode 'complex' to cover such a complex 
> animation behaviour. And of course, for such
> a complex behaviour, the animation function
> should be explicitly and understandable defined
> to be understandable for an average author.

You forget that the matrix decomposition is the fallback. The average author will write their animation as a list of transform types - which is the easiest to understand.

> A good approach would be of course just to leave
> the old attribute transform as it is and to
> introduce a new attribute transform2D to avoid
> most incompatibilities and to allow authors in the
> future to get access to this not only as a decorative
> issue with CSS. Of course this would be a big advantage
> of millions of existing SVG documents too, because there is
> no risk of backwards incompatibilities in the drafts or 
> implementation problems for the old documents.

Really? Millions of existing SVG documents that use animation of matrices, and will now have a stylesheet applied to them that provides a transform?

Note that no standalone SVG document will change behaviour.

> The separation could work similary to animateMotion
> (and its attribute rotate) as additional transformations, one
> just has to define a proper order of all these independent
> transformations - well it is just one more with transform2D.

So you suggest a new SVG attribute that corresponds to a CSS property with a different name, and is, for the vast majority of cases that any author would care about, identical to an existing attribute with a similar name, but it is not clear which has precedence or how they are combined? I think that's a terrible idea.

Also, I guess you'd want to add a third attribute, transform3D, if/when 3d transforms are specified.

Dean


> 
> Olaf
> 
>

Received on Friday, 12 March 2010 18:26:01 UTC