- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Sat, 31 Oct 2009 16:49:57 +0200
- To: www-svg@w3.org
Jonathan Watt: > On 2009-10-31 12:06 PM, Dr. Olaf Hoffmann wrote: > > 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. > > I don't see any conflict between the proposal for attributeType="CSS" and > "what is already defined in SMIL implictly". Can you give a concrete > example of a conflict that you see? > > > 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. > > For complex types there will sometimes be ambiguity about exactly *how* > they should animate, yes. We should clarify the cases where we realize > there's an issue ahead of time, and if implementers raise new questions > about others as they implement, then we should clarify them at that point. > This is what I meant, it is not directly the question, whether it is animatable or not, but what has to be written in the specification for example whether it is additive or not or only discrete or if there is a meaningful way to perform a paced animation. This applies to both attributes and properties. This means just, if you remove general restrictions, you have to look at the same time on each property or attribute to see, what you have to add as information about for example additive behaviour. This does not mean, that one should not remove general restrictions. It means only, that one has to be careful, if this is done. It means: Don't forget to fix all these nasty little things *before* you remove general restrictions. The best for a proposal would be to create a list containing all questionable properties (or attributes) and to provide what has to be written for each of them to avoid a situation with ambiguous behaviour for one of them. > >> 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. > > There's no way to prevent an author from confusing their audience if that's > what they want to do. I see no good reason to animate these properties, but > equally I see no good reason to explicitly prohibit them from being > animated. > > > In SVG 1.1 we have others: > > 'writing-mode', 'glyph-orientation-vertical', > > 'glyph-orientation-horizontal', 'enable-background'. > > You can change these with script, so I see no good reason to actively > *prohibit* changing them with SMIL. > Personally I'm not against removing such restrictions, because in most cases I cannot see important reasons either. The same applies for example fot the matrix type of transform - not obvious for me, why this is not animatable ;o) The related CSS property is animatable (but the behaviour is unfortunately a little bit opaque hidden in a C-source code, maybe with some missing procedures - and from my point of view the SMIL approach of animating it would be quite different). Maybe Chris Lilley has still in mind, why those properties and some attributes were indicated to be not animatable. He or someone else from the 'old times' is hopefully able to explain, what the intention is or was. For me it is no big difference, I just have to add 10 to 100 more tests to my animation test suite - no big deal ;o) And in doubt, then I will find out, if there is something forgotten or ambiguous in the behaviour. I think, except for something like the matrix type of transform they should be typically non additive and discrete, therefore almost simple. But glyph-orientation-* 'angle' - additive or not? Discrete or not? It is defined, how to round, the value could be animated continuously as well. Needs to be clarified however before one can remove the restriction. > >> 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. > > I never proposed mixing. > > > 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, > > I only looked in CSS animations for restrictions and saw none - I > erroneously assumed that the same was true of transitions. Anyway, my point > is that I don't see any need to restrict what SMIL can animate relative to > *either* of these CSS proposals. > This could be an issue for the CSS animation proposal es well. http://www.w3.org/TR/2009/WD-css3-animations-20090320/ In 1 it notes: 'This specification is an extension to CSS Transitions' and in 3: 'Animations are similar to transitions in that they change the presentational value of CSS properties over time. The principal difference is that while transitions trigger implicitly when property values change, animations are explicitly executed when the animation properties are applied.' My interpretation was - if there is no other principal difference - that the transition proposal defines as well, what is animatable, especially it http://www.w3.org/TR/2009/WD-css3-transitions-20090320/ interestingly notes in 5 'Animatable properties' and not 'Transitionable properties'. Maybe one has to ask the authors of the proposals to clarify, what this means ;o) However, one can animate discrete, but one cannot transition discrete. On the other hand, for discrete animation on needs a more precise time interval model as SMIL has, but not the CSS proposals. On has to define precisely such 'events' like :hover, :active and :focus as well to compare to SMIL concerning a proper timing, else authors have to use SMIL anyway to get something predictable ;o) Olaf
Received on Saturday, 31 October 2009 15:03:13 UTC