Re: Some thoughts on css transforms in svg

Dean Jackson:
> 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.
>

For SVG the details about interpolation are always defined in SMIL,
not in SVG (there are only a few exceptions), therefore one cannot
derive a proper animation behaviour from the SVG recommendations alone. 

And to interpolate only between the provided values (the items in the list
within the values attribute) is a general basic concept from SMIL (including
the equivalences for from-to, from-by and by animations), therefore one
would have to define the CSS-transform behaviour with decompostion
completely independent from previous recommendations (SMIL and SVG),
because it results in completely different interpolations as possible with
SMIL/SVG currently - additionally the current CSS draft has no concept of
additive behaviour and much more, one has to adopt from SMIL to keep
it compatible and consitent).

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

Indeed, this was always surprising to me - and up to now no one could/did
explain this ;o)
To have it animatable is already a progress in the CSS draft, but the
exclusively complex decomposition interpolation is not always, what will
be effective, therefore it would be a progress anyway to add the calcModes
linear, spline and discrete, I think paced is not applicable for matrix,
because there is no meaningful distance between two matrices leading to
something paced ...


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

But currently authors cannot specify another behaviour like linear for
matrix, if they need it, expecially more useful, if one needs to approximate
some specific interpolation with a predictable error margin without
blowing up the source code.

Furthermore the CSS-concept how to animate a transfrom property 
is completely different from that specified in SVG for the attribute -
therefore these are anyway to completely different things, would be 
strange to have a completely different behaviour for the property than 
for the attribute.

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

No there are millions of SVG documents animating some transform
attributes with animateTransform. And because the CSS draft does
not fit in most cases to what is defined for SVG, either one aligns
the CSS draft to what is defined already for SVG or one gets a
backwards incompatible mess. And concerning paced animation
the mess in SVG 1.1 was just fixed in SVG tiny 1.2 with much efforts,
why to risk new unneccessary mess with some new tinkering around 
at this complex issue?

> Note that no standalone SVG document will change behaviour.

We will see, what will be mentioned in a draft, that applies to
SVG as well ... ;o)
Due to my experience of the last years with what happened in the
first six or seven years of SVG about animation and transformations,  
things have the tendency to get wrong pretty fast and for a long time ;o)
There is no need to repeat this with the CSS draft or new drafts for
SVG.

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

After reading the CSS draft, concerning animation it will be completely
different (what is not necessarily bad, just not compatible with the
current animation behaviour).

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

I'm pretty sure, a nice name can be found, before the CSS drafts gets in
a more advanced state ;o) Because the 3D-transfrom has more types anyway,
it would be anyway an advantage to separate this from the current SVG
transform attributes.
With such an approach I think it would be simpler for authors to create
documents with some default simple behaviour for old viewers and some
3D-effect for new ones - what would be much more difficult with only one
transform attribute.

Olaf

Received on Friday, 12 March 2010 20:26:29 UTC