- From: Brian Birtles <birtles@gmail.com>
- Date: Mon, 28 May 2012 14:45:18 +0900
- 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 UTC