Re: Changing attributeType="CSS"

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.

>> 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.

>> 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.

Jonathan

Received on Saturday, 31 October 2009 12:23:01 UTC