- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Fri, 30 Oct 2009 21:04:36 +0200
- To: www-svg@w3.org
I think, SMIL requires, that a format specifies, which attributes and properties are animatable. And in some cases one has to find out even more details (for example if a meaningful distance exists is concering paced animation for complex types). If 'defined as animatable in this specification' is removed, what defines, what is animatable and what could be the purpose to indicate which one is animatable and which one not? It might have reasons, if something is indicated to be not animatable (maybe it would help to indicate the reason in the specification, however, to avoid more questions). One problem was already discussed and improved for the case 'auto' in SVG tiny 1.2: If 'width' and 'height' from CSS is animated, how to animate the attributes 'width' and 'height' for example for a rect? What to animate, if 'CSS' is indicated? Currently nothing for a rect, because they are not applicable and not indicated to be animatable for rect. No problem, no conflict with the related attributes. And about: "It would seem better not to impose an artificial limit, and to enable parity between SMIL animation and CSS animation.' attributeType is always related to SMIL animation and nothing else. For attributeType XML an attribute is animated and for attributeType CSS a property, both with SMIL animation. And in both cases the SVG specification notes for every attribute or property, whether it is animatable or not. I cannot see any disparity, expecially because for attributeType XML is noted too: 'The attribute must be defined as animatable in this specification'. Or do you mean the current CSS proposals for transitions and animation? I think, this attribute is not related to these proposals, they define on their own, what is animatable concerning CSS animation and such a property animated within CSS is 'somehow' integrated at some level in the SMIL sandwich model automatically, I think, because it is derived from a stylesheet, it has lower priority than an animation with attributeType CSS, if the same property is animated with SMIL too at the same time. Obviously this should be avoided by authors, because it causes even more complexity than what we already have now (and what was originally not really intended, as Chris Lilley mentioned already several times, but is now nevertheless defined in the SMIL sandwich model).
Received on Friday, 30 October 2009 19:14:57 UTC