Re: Changing attributeType="CSS"

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