Re: Some thoughts on css transforms in svg

On 13/03/2010, at 7:21 AM, Dr. Olaf Hoffmann wrote:

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

I know. My point is that even SMIL does not say how the interpolation calculation is performed on complex types, such as transform (*). It tells you how to derive the "progress" along the timing function, but does not tell you what algorithm to use between two values.

(*) the exceptions are animateColor, which says it is on a per-component basis, and path animation.

Therefore, matrix decomposition is just as valid as interpolating the matrix components.

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

We already have linear and spline in CSS animations.

There is a standing proposal to add 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 -

Like I said, SVG doesn't tell you how to animate a transform 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.

You missed my points.

1. Without any new stylesheets applied that override the transform on existing SVG content, nothing will change.

2. SMIL animation of SVG transforms is restricted to animateTransform, which is always separated by component. This is not incompatible with CSS.


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

No.

#some-element {
  transform: translate() scale() rotate();
  transform: translate3d() scale3d() rotate3d();
}

The first rule is accepted in all viewers. The second rule fails if you don't do 3d, and you fall back to the first rule. Also, you'd probably separate by media queries, to make the code more readable.

Compare to your suggestion:

<rect id="some-element" transform="translate() scale() rotate()" transform2d="translate() scale() rotate()" transform3d="translate3d() scale3d() rotate3d()">

Dean

Received on Friday, 12 March 2010 20:50:57 UTC