Re: SVG animate values format

I think (my personal analysis), from the general SMIL point of view it 
depends on the animated attribute or property, if this allows "" (nothing) 
as value, then it is ok to write values="0;0;90;", if not, then this notation
is not ok (what is true for most or even all attributes or properties).

In this case, because the rotate-angle is not optional and it is noted
for transformations: 'All numeric values are real <number>s.'
and "" is not a real number, the value list above is not ok for transform 
rotate.

Therefore the rule from C.2 for unsupported values applies:

'For known elements in the SVG or XML Events namespaces, unknown attributes 
that have no namespace and known attributes with unsupported values are 
treated as if they hadn't been specified when rendering. Unsupported values 
are defined in the definitions section.'

Anyway this only removes the invalid value "", not the ";" from the values
list. Therefore there is still a problem for the animation.

For the animation it applies from C.2:
'The user agent must not stop processing or rendering under any of the above 
situations, but at user option it may alert, log, or otherwise provide a 
notification that unsupported content was encountered.'

I think, there is no specific rule in SVGT1.2 what happens with the animation
in such a case of an invalid value, but the animation chapter refers to SMIL 
2.1 for details, there can be found:
http://www.w3.org/TR/2005/REC-SMIL2-20051213/animation.html#animationNS-SpecifyingAnimationFunction

'values
A semicolon-separated list of one or more values, each of which must be a 
legal value for the specified attribute. Vector-valued attributes are 
supported using the vector syntax of the attributeType domain. Leading and 
trailing white space, and white space before and after semi-colon separators, 
will be ignored. 

If any values are not legal, the animation will have no effect (see also 
Handling Syntax Errors).'


And 'no effect' means, that there is no visual presentation effect for the 
complete animation, but the timing is still computed, the animation can be
still used to derive some syncbase-values (with four values in the values
list, if this is of any interest, how much they are).

I think, this will be the final 'error handling' for this animation example.

Received on Wednesday, 28 May 2008 09:00:40 UTC