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

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

From: Brian Birtles <birtles@gmail.com>
Date: Mon, 28 May 2012 14:45:18 +0900
Message-ID: <4FC310EE.7040807@gmail.com>
To: Dirk Schulze <dschulze@adobe.com>
CC: "public-fx@w3.org" <public-fx@w3.org>
Hi Dirk,

Thanks for getting back to me on this.

(2012/05/28 13:11), Dirk Schulze wrote:
> I am a bit unsure about deprecating 'animateTransform'.

Fair enough, feel free to leave it for now. We can talk about this in a 
telcon.

For now, I have a couple of thoughts in response.

> First, even on deprecating it, implementations are still forced to implement it in the future, because so much content relies on it.

Yes, I agree we still need to describe it and implementations will still 
need to support it for some time, but I think we should discourage its 
use (reasons follow).

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

animateColor is not in Gecko and not likely to be. I don't think there 
is sufficient content using it to justify supporting it in future. It's 
trivial to implement but it clutters the Web platform. There were good 
reasons for introducing it at the time, but they no longer hold. Now it 
achieves nothing.

Also, as I think we agree, we're trying to move away from any explicit 
dependence on SMIL, so whether animateColor is in SMIL 3.0 or not, makes 
little difference.

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

I agree, they behave differently but I think that's a problem. Going 
forward authors will have two ways to achieve very similar results.

e.g.

<animateTransform attributeName="transform" type="translate" from="0 0" 
to="100 100"...
-or-
<animate attributeName="transform" from="translate(0 0)" 
to="translate(100 100)" additive="sum"...

I'd like to say to authors, "Forget about animateTransform, just use 
animate. Everything you already know about animate 'just works' with 
transform lists, no need to lean extra elements and attribute."

Only implementers should need to worry about animateTransform and all 
the counter-intuitive and undefined (sometimes explicitly so, sometimes 
not) behaviour that goes with it.

> With CSS Transforms, we create a Matrix and decompose the matrix again.

Oh, that's unfortunate. That's probably the best reason for keeping 
animateTransform, but still not enough in my view. This is something we 
can talk about later.

 > Therefore, 'animateTransform' could still be useful for authors (just 
to have a better understanding of what happens).

I don't understand this.

Thanks again Dirk. Like I said, don't worry about deprecating this for 
now. It sounds like we need to talk it through more.

Best regards,

Brian
Received on Monday, 28 May 2012 05:45:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 28 May 2012 05:45:53 GMT