- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Mon, 31 Jan 2011 16:30:42 +0100
- To: Ken Stacey <ken@svgmaker.com>, www-svg@w3.org
Ken Stacey: > > Something like RT * MP * MR * AS does not fit to SMIL/SVG at all, > > this would be very odd - > > Odd as it may seem, this is how ASV and Opera have appeared to implement > it. This is clearly a bug, because for all versions of SVG it is required to postmultiply an additive animateTransform to the underlying value (this can be another animateTransform with lower priority or in this case simply the value noted in the transform attribute). To change this, requires to change the complete concept of additive animateTransform. Well, animateTransform has already some other problems like that of to-animations, but this should be no reason to corrupt the concept just because in some viewers there is a bug, if there appears an additional animateMotion, that has - up to now - nothing to do with additive animateTransform oder animateTransform at all ;o) > > > or this means basically to define that animateMotion is not > > supplemental to animateTransform, more an alternative way to provide > > an animation of the transform attribute with only translation and > > rotation - but then the order of begin times and the order within the > > source code of animateMotion and animateTransform becomes important > > as well - including the conplication to indicate them to be additive, > > if itis required that the later one does not replace the earlier > > one. > > I think all it means is that animateTransform is supplemental to > animateMotion. Well this means either RT * AS * MP * MR or MP * MR * RT * AS or MR * MP * RT * AS for the given example. > > I agree that giving equal status to animateMotion and animateTransform > does introduce some complications. This would happen for RT * MP * MR * AS for example, if there are several additive animateTransform elements with several begin and end times - therefore the underlying value changes all the time, sometimes it is the RT, sometimes the current value of another animateTransform or a combination of that. Finally there is not just one animation effect for the related attribute, it is some mess of changes of something, nobody really has a name for ;o) This could be only avoided by indicating, that animateMotion is not supplemental, but only contributing to this sandwich model of transformations. Here as typically it is much better simply to fix the bug in the viewers instead of corrupting a well considered concept in the recommendation ;o) Fixing the bug simply solves the problem. Corrupting the recommendation mainly results in something we can observe in the HTML5 draft - a lot of complex and hardly to understand rules based on bugs of viewers, not really meaningful or simple to keep in mind for authors and implementors. Olaf
Received on Monday, 31 January 2011 15:31:17 UTC