W3C home > Mailing lists > Public > public-fx@w3.org > April to June 2012

Re: [css3-transforms] remove 'animateTransform' definition from spec

From: Dirk Schulze <dschulze@adobe.com>
Date: Sun, 27 May 2012 21:11:23 -0700
To: Brian Birtles <birtles@gmail.com>
CC: "public-fx@w3.org" <public-fx@w3.org>
Message-ID: <3D042D39-1E5B-4719-9E09-F9A1D2E6180A@adobe.com>

On May 27, 2012, at 7:25 PM, Brian Birtles wrote:

> (2012/05/26 6:28), Dirk Schulze wrote:
>> Hi,
>> 
>> The current version of the CSS3 Transforms specification has a section that partly redefines the 'animateTransform' element [1]. I think it makes rather sense to add the changes to the SVG Animation section [2] directly. This would reduce confusions for looking on different specs just for the definition of the element itself. I am willing to edit the SVG Animation module to interact with CSS3 Transforms. It will mean that SVG 1.1 will not support the new transform functions. SVG 2 on the other hand is a bit more clear and cleaner in general and will support all transform functions of CSS3 Transforms. I don't see any incompatibilities for SVG 1.1 so.
>> Are there any objections? Otherwise I will remove this section and edit SVG directly.
> 
> Sounds good. While you're at it, you could probably mark 
> animateTransform as deprecated. There seems to be consensus that it 
> should go.
I am a bit unsure about deprecating 'animateTransform'.

First, even on deprecating it, implementations are still forced to implement it in the future, because so much content relies on it.
Second, we already deprecated 'animateColor' along time ago and it is still in use. Now that it is officially part of SMIL 3.0, I wonder if we undeprecate 'animateColor' again.
Third, animation with 'animateTransform' and 'animate' is still very different in my eyes:

'animateTransform' changes a new transformation matrix, that gets multiplied with the original 'base value' of the element. It never overrides the current transformation of the element. Animations with 'animate' override the base value directly, without creating a new transform that gets post multiplied. Even if you can easily get the same behavior like with 'animateTransform', it is a different approach.

> It's not needed when <animate> can target a transform list 
> (as the Transform spec now allows) and it's confusing that it can only 
> deal with a single transform despite targetting a list.
It is confusing, yes. I guess it is partly related to the additive behavior that is a lot easier to define with single values of the same type. With CSS Transforms, we create a Matrix and decompose the matrix again. This approach was not used for SVG Animate. But this is also the reason why you can't rely on animations with values like -360 to 720 in one of your previous examples. With the matrix and decomposing, they get modulated. Therefore, 'animateTransform' could still be useful for authors (just to have a better understanding of what happens).

Greetings,
Dirk

> 
> Best regards,
> 
> Brian
> 
Received on Monday, 28 May 2012 04:11:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 28 May 2012 04:11:55 GMT