Re: [SMIL30 LC comment] 3.4 and 3.6

> > --------------------
> >
> > 'Specifically, animating an attribute defined in XML will modify the
> > presentation
> > value before it is passed through the style sheet cascade, using the XML
> > DOM value as its base. Animating an attribute defined in a style sheet
> > language will modify the presentation value passed through the remainder
> > of the cascade.'
> >
> > -> For example the style sheet language CSS has properties and no
> > attributes, what about them?
> > Does XSL have attributes (I think, it has mainly formatting objects and
> > properties)? Which style sheet language defines attributes?
> > Better:
> > 'Animating an attribute or property defined in a style sheet language will
> > modify the
> > presentation value passed through the remainder of the cascade.'?
> > or if there are no attributes in style sheet languages:
> > Animating a property defined in a style sheet language will modify the
> > presentation value passed through the remainder of the cascade.'?
>
> Added "or property".
>
> > -> If we take as an example a basic shape from SVG, for them 
> > presentational XML attributes and CSS properties exist with the 
> > same meaning and the same name, for example the property/attribute 
> > fill. If we use attributeType XML and CSS we can distinguish between them.
> > This paragraph means that the animation using attributeType XML is
> > applied before it is passed through the style sheet cascade, while
> > with attributeType CSS (or auto) it is applied to the remainder of the
> > cascacde. Is this correct? This means animations using attributeType
> > XML are overwritten for example by external author style sheets, because
> > those are later in the style sheet cascade. But using attributeType CSS
> > means, the animation superseedes the style sheets again (if there is no
> > !important from a user style sheet). Is this correct?
>
> You are correct on both counts here.

I see, I think, this has to be discussed in the SVG WG then ;o)
I do not insist to be correct here, but if the SMIL WG agrees, ok.
There were other opinions on this, partly depending on 
personal memories about the history of SMIL and SVG.
We will see, if this solves the problem and SVG test cases
can be created now...

.....

>
> > --------------------
> > 3.4.6 Additive animation
> >
> > 'An element may be defined as additive only if addition is
> >  defined for the type of the target attribute.'
> >
> > -> What happens, if this is not explicitely specified for the
> > target attribute? No animation at all?
>
> This is a requirement for the author of a SMIL profile.  If this is not
> done, the profile is erroneous.  The spec can and should not assume that
> such a thing can happen.

Ok, fine, this was only mainly related to (silly?)
trials to animate CSS properties from outside SVG, given for the
svg element in a compound document, for example CSS 
width and height instead of SVG attributes width and height 
using attributeType="auto" ...


.....

> >
> > 3.6.2 Specifying the simple animation function f(t)
> >
> >
> > - What is recommended for calcMode paced, if there is
> > a known procedure to produce an even pace of change
> > across the animation, but this procedure does not interpolate
> > between the values? This happens for example for a list
> > of numbers or coordinates as animated values.
> > Such lists are no vectors, sometimes lists of vectors.
> > Fallback to linear?
> > A SMIL3 example is the new viewBox, as already commented.
>
> There is already a restriction in place which says that it must be
> possible to calculate a "distance" between points.  Isn't this
> restriction enough?  We have a hard time envisioning a distance function
> between e.g. viewBox values, but if it is possible, then this distance
> can be used.
>
>

One can define a lot of different formulas, not related to a paced 
chance of the appearing things (or however one might call it).
For example one could define the Manhattan distance for animateMotion
with a value attribute. Beiing in Manhattan or areas with similar maps,
such a distance is quite useful, but not related to a paced change in
general. 
Therefore one has to derive the 'correct' distance definition from
the 'appearence' of the object represented by the attribute, this is
for example for animatMotion as for other vector like values the
Euclidian distance and not the Manhattan distance.

Now we can identify something like a distance definition for 
viewBox too, however, this is in conflict with another condition for
a paced animation, that it has to interpolate between the values.
In SVG there are other objects, one can identify a paced behaviour
of such objects, but the derived formulas do not interpolate 
between the given values.

My opinion about this is, that because not both conditions can
be fulfilled, there is no defined behaviour for calcMode paced,
if the attribute does not represent a vector or a scalar.
If it represents for example only a list and not a vector
(a vector has an absolute value and a direction, a general list
has not), there is no paced behaviour and something like
a fallback is required, if an author anyway write calcMode="paced",
because the author did not see the problem for whatever reason.

Received on Thursday, 25 October 2007 13:07:51 UTC