Re: Changing attributeType="CSS"

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

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 

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