Re: animate-elem-46-t.svg

Boris Zbarsky:
...
>
> > At this point it does not really matter, who defined the property or
> > the attribute. If it exists, one can apply an animation effect to
> > it independently.
>
> Well, that's the issue here, no?  At what point is the string in the
> SMIL attribute converted into a value?  Who's responsible for defining
> the conversion?

You can ask the SYMM group as well, what they think ;o)
My observation is, that SMIL typically does not define this.
It does for example for colors, because it mentions something
like the interpolation takes place in the RGB space and the
Euclidian distance function has to be used. 
From this an implementor can derive a method to get it
right. SMIL does not write, that one has to convert all colour
channels to for example the percentage notation to do the
interpolation. There are some restrictions on rounding and
clamping, therefore typically with the short hexadecimal
notation the result might be wrong, therefore not a good
choice. Within the SMIL animation even negative and other
out of range values are ok, the clamping is only done for
the presentation. The implementor is free to use its own
color space for interpolation, as long as the final result
in presentation is not distinguishable from what you get
with interpolation with floating point numbers and rounding
and clamping is applied to the presented things and not
in the middle of the animation.

Another thing, SMIL defines for its own animateMotion
(what differs slightly from the SVG animateMotion),
that coordinates are numbers.
In the section about the attribute 'origin' they talk
about CSS. Surprisingly it does not contain any 
explanation about the units problem. But obviously
this is required, therefore it ever applied, the host language
has to define the relation between the numbers in
SMIL animateMotion values and CSS coordinates/lengths.

The definitions of set and animate do not care about units,
therefore my assumption is, that SMIL does not feel responsible
for something more complex than simple numbers and colours.
The host language has to do this, as SVG defines for length,
how they are related and related to numbers.
As long as all values are converted into values with the same
unit, SMIL can be applied.
I think SVG does not exclude that an internal unit is used for
interpolation, however, if someone notes values="2px;2pc;2cm"
it is expected, that these lengths are presented, something with a
length of 2px at the first keyTime, 2pc at the second and 2cm 
at the last.

> >
> > The host language defines the meaning of attributes and properties
> > (roughly what you put in and what you get out of the SMIL machine
> > and what presentation the output might cause).
>
> I'm not looking for "meaning"; I'm looking for syntax constraints.  Can
> you please cite where the SMIL spec says what defines the syntax of
> attributeType="CSS" animations, if anywhere?

Well, I think, I have not seen more about this than you.
I think, it only mentions something about this in the section about
the sandwich model and in the section, that defines this attribute:

"CSS
This specifies that the value of attributeName is the name of a CSS property, 
as defined for the host document. This argument value is only meaningful in 
host language environments that support CSS."

In our case SVG as the host language has to define, what a property is and
how authors can note them as properties to be applicalble for the host
document - in SVG this means, using the CSS syntax or maybe a DOM 
method to apply properties (I don't use scripting, therefore I never 
cared about this aspect of SVG).


>
> > In detail, we can have this choice:
> > normal |<number>  |<length>  |<percentage>  | inherit
> > therefore here 2px is not the same as 2.
>
> Right.  Neither is it for CSS syntax in general, of course; it's just
> that here the value space includes both positive integers and lengths,
> which it doesn't for most properties.
>
> The question, again, is the point at which conversion from strings to
> values happens and the rules to be used.
>
> > SMIL itself does not claim, that 2px is the same as 2.
>
> OK.
>
> > To be able to animate values="2;2px;2%" continuously,
> > something outside of SMIL is required to get the same unit
> > for all values to calculate the animation effect.
>
> So is the "something outside" basically responsible for converting those
> strings to values?

Sure, you will not find anything about this.
I think a case like values="2%;20%;200%" is trivial enough to
work without an explanation from the host language. 
There are numbers with the same unit - everyone with some
basic level of education can interpolate between such structures
and one does not even have to know, what '%' means to do it.
This is different for values="2;2px;2%". 
For this you need non trivial explanations to interpolate.
And for this you will not find an explanation in SMIL. 
Units and explanations may differ between different host
languages (like SVG, XHTML, CSS), therefore SMIL has
not the possibility to explain all this.

>
> What exactly does the override stylesheet language in SMIL3 (which seems
> clear enough to me, for what it's worth, but I want to make sure I'm not
> missing something) mean to you?

With only SMIL nothing specific.

If the host language defines such a language, as SVG does in the styling
chapter, this is applicable within SMIL.
For the note about SMIL+XHTML they talk about CSS as well, but
I think, the animateMotion example in this note is questionable due
to the problem, that the units required by CSS are missing and neither
the note nor SMIL defines, what the numbers mean for CSS lengths/coordinates.
microsoft implemented this, maybe we have to ask, what they assume what
the numbers mean for generic CSS in XHTML ;o)

But sure, the section about the sandwich model refers several times
explictly to CSS or CSS2 and DOM2CSS.
For them it seems sufficient to refer to these resources to explain, what
CSS is.
However with the definition of the attributeType they finally say, that
the host language has to define the CSS properties.
The assumption seems to be, that the referenced resources about
CSS define the basic syntax of CSS and the host language defines
the usable properties and their values. 
I think, this fits to the usage in SVG.
SVG defines a length different from CSS, therefore this applies
according to SMIL.
If the host language does not define something specific or at least that
properties of CSS as defined therein are applicable, one cannot assume 
that CSS properties are animatable at all in such a language.
I think, this is a problem for this SMIL+XHTML+CSS construct, it is
not detailled enough about this without some creative assumptions
of the reader ;o)

>
> > Without additional information from the host language,
> > SMIL animation falls back to calcMode discrete,
> > no continuous animation.
>
> That doesn't matter for my purposes; I don't care how the interpolation
> between values happens; I care about what the values mean to start with
> and how the UA is supposed to determine what values the strings
> correspond to.
>

I think, it matters, because this is the place where you get information about
what to do, if the host language does not provide sufficient information about
values and whether it is intended, that they are interpolable or not:

"calcMode
Specifies the interpolation mode for the animation. If the target attribute 
does not support linear interpolation (e.g. for strings), or if the values 
attribute has only one value, the calcMode attribute is ignored and discrete 
interpolation is used."

For something like values="SVG;CSS;XHTML" or values="0.2kg;3g;400mg"
or values="#f00;#0f0;none;#00f" (SVG sample) 
without further explanation from the host language the SMIL solution is not to 
interpolate, those have to be treated as strings.
values="0.2kg;3kg;4kg" looks simple enough to assume that this supports
linear interpolation, if the host language does not explictly note, that these
values are not intended for interpolation. Typically the host language will
only note, that the value is a mass, a number immediately followed by a 
mass unit. Numbers are ok to interpolate and additional units are no
restriction. If it is defined that 1kg=1000g and 1g=1000mg there is no
problem to interpolate the other mass example as well.
Different situation for CSS/SVG font-weight: values="900;300;600"
Due to the definition of the property, one can assume, that interpolation is
not intended and the numbers are treated as strings. 
Obviously SMIL cannot know or define this. This always depends on the
definition/meaning of the property or attribute.

Therefore my assumption is, that before putting anything into the
SMIL machine, one has to identify the syntax of the values and
decide about what calcMode applies. Then one has to transform
the values in case of interpolation into one number space (and keep
in mind the unit). These numbers or lists of numbers or parameters
(see the problem with inherit and currentColor) go into SMIL.
The unit kept in mind and the result from SMIL is joint together
again to get the current presentation value.
Other methods may work as well, but I think, typically they will
be even more complex. And there seems to be no specific method
recommended to get the current presentation value. 
The choice of method seems to remain the problem of the
implementor. One can only test, that the presentation value
fits to the values lists, not what happened between reading 
the values list and the presentation.


Olaf

Received on Thursday, 10 June 2010 10:35:47 UTC