- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Fri, 12 Mar 2010 21:21:19 +0100
- To: www-svg@w3.org, public-fx@w3.org
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. 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, 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 - 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. 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. Olaf
Received on Friday, 12 March 2010 20:26:40 UTC