- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Sat, 31 Oct 2009 13:06:31 +0200
- To: www-svg@w3.org
Jonathan Watt: >> 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). > >I don't follow why this relates to determining whether a property is >animatable. You have to do more than just to indicate, that this is animatable, you have to do some research, how to animate this without creating a conflict with what is already defined in SMIL implictly. Of course we can say, that this belongs to the process to determine the animatibility of a property or attribute, but this is in some cases not as trivial as to note 'animatable', else we get the funny situation as with the animation of 'transform' in SVG 1.1 or within some drafts of SVG tiny 1.2 for some complex types. >Are there any properties for which you would want to specifically prohibit >animation? If so, why? If not, maybe the animatable entry in the property >tables should just be removed. If we have a look into SVG tiny 1.2 property table, we find only 'direction' and 'unicode-bidi' to be indicated as not animatable. It is not explained, why they are not animatable, but one can guess, that this happened to protect author from doing things, that can confuse the audience on a very basic level of understanding the document purpose itself. In SVG 1.1 we have others: 'writing-mode', 'glyph-orientation-vertical', 'glyph-orientation-horizontal', 'enable-background'. If/because there is no reason explicitly mentioned, why they are not animatable, this can be interesting to discuss of course. And if it turns out, that there are good reasons not to animate them this should not be changed (especially because the same or a similar effect can be typically realised with an animation of other attributes or properties, maybe with less influence on the basic level of understanding). But in general I agree, if there is no good reason known, why they are indicated to be not animatable in the full profile, this should be changed in the next version of the profile. >I'm saying that with the current CSS proposals for transitions and animations >you can animate more properties than you can with SMIL animation. Why would >we (or anyone) want that to be the case? I read and commented these proposals already and this is anyway not much related to SMIL animation. It uses a completely different approach and should not be mixed with the more advanced and more complex SMIL approach. It has some advantages in its simplicity and especially the transition proposal provides an interesting functionality, one does not have with SMIL at all or not in a simple way. And looking in the current CSS transition draft indeed the opposite is true, there are only a few properties indicated to be animatable, much less than available for example in SVG tiny 1.2 for animation. One reason for this seems to be the simplicity of the CSS approach - what can change of course with a more advanced CSS proposal with less simplicity. I think, because the CSS approach is quite different from the SMIL approach, this should not be mixed up. The only thing one has to do for the CSS approach is to note explicitly and understandable the position of the CSS-animated-or-transitioned property values within the SMIL sandwich model, that implementors can adjust this properly, avoiding annoyance for authors and users with implementations with different priorities. The main 'historical' issue with attributeType is, that it would have been more useful in the early days of SMIL to define something like a pseudo-namespace-prefix for CSS, then there would be no need for such an attribute and one could simply write something like xmlns:css="http://www.w3.org/Style/CSS/" attributeName="css:color" as one can write xmlns:xlink="http://www.w3.org/1999/xlink" attributeName="xlink:href". But now it seems to be a little bit late for such an improvement.
Received on Saturday, 31 October 2009 11:27:48 UTC