Re: animate-elem-46-t.svg

Boris Zbarsky:
> On 6/9/10 8:57 AM, Dr. Olaf Hoffmann wrote:
> > Boris Zbarsky:
> >> Now the question I don't know the answer to is what SMIL actually does.
> >
> > It defines how to animate features:
>
> Yes, yes.  Or at least it tries to define.
>
> > I think, the host language has to explain, what the value is.
>
> If you define "host language" broadly enough, yes.

Last time I read the LC for SMIL3 I think I
have seen somewhere a definition.
In case of SMIL in SVG, SVG is the host language, which
reuses parts/modules from SMIL.

Concerning the note about XHTML+SMIL I'm not sure
about the host language. Looks like the construct of the
note, a combination of SMIL and XHTML plays the role
of the host language.

>
> > SMIL only explains how to get an animation effect function.
>
> There's a lot more than that in the SMIL spec last I checked.  In
> particular, it talks about base and animated values, override
> stylesheets, etc.  Sure sounds to me like at least in the latter case
> the output of SMIL is strings, not values.
>

Yes, my understanding is (and I tried to check or to disprove
my assumptions within the SYMM mailing list), that they 
assume an XML like language (fits to SVG or XHTML) with
some additional styling features in another language construct
such like CSS+XHTML or the SVG/CSS combined construct
of the SVG recommendations.
Some DOM is mentioned as well, but not really required.

This results in at least two abstraction levels.
The first is the XML like language. 
In doubt to address a feature in this, one can use attributeType="XML".
attributeType="CSS" addresses the CSS like structures.
You can use if, if both have features with the same name (that has
to be noted within the attributeName). Both together and href from
XLink or SMILs other targetting mechanism to identify the animated
element are used to identify, which feature is animated.
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.

The animation of the XML type uses the value of the presentation attribute 
or the result from other animations of the XML type as underlying value,
if additive behaviour is required. 

Now it happens, that CSS or SVG specify, that presentation 
attributes contribute to the CSS cascade with a low specifity
of some property, typically with the same name as the presentation
attribute.

If the viewer interpretes styling with CSS, it has to use the
animation effect result for the presentation attribute on this
level of specifity.

Applying this cascade results somehow in some final value
of a property. Often this might cover the animation of the
presentation attribute completely, if there are additional stylesheets
to apply to the property.

However, the CSS type on SMIL animation uses this final
result from applying the CSS cascade as underlying value -
or another animation of the same type.

One problem with the nasty attributeType is, that according
to what Chris Lilley mentioned already several times in similar
discussions, originally the complete construct was
intended to be much simpler, with only one abstraction level,
not two, all would have happened on top of the cascade.
Obviously, this simpler model did not survive the review
process of the initial SMIL animation recommendation and
the attributeType appeared with the implication of two
abstraction levels as soon as something like SVG claims
to define both (presentation) attributes and properties
with the same name - or alternatively it might occur the
problem often discussed: The CSS properties width
and height and those attributes from SVG with the same
name, not beeing presentations attributes. Therefore a
change of the property does not change the appearence
of the related element, and the attribute does not contribute
to the CSS cascade.
This increases the probability, that a user agent starts to animate
the CSS properties width and height instead of the SVG attributes 
width and height, if no attributeType is set. 
Therefore the wording is already choosen more carefully in 
SVG tiny 1.2 to avoid as much surprises as possible without the 
need for authors to use this attribute at all - in doubt with the result, 
that external stylesheets or something noted in the style attribute will 
cover all animations,  if attributeType="XML" is used 
(I have already seen such samples in the past and people beeing 
excited about  this observing it in Opera 8).
Altogether all this is unpleasantly complex.
But to ignore it by ignoring the attribute may result in even more
nasty surprises.

> > The host language has to define, what attributes, properties and
> > different units of values mean and how such units are related.
>
> Is that true, though?  SMIL explicitly talks about attributeType="CSS"
> in terms of the override stylesheet and so forth; the behavior of that
> is defined by CSSOM and CSS, not by the host language.

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).
SMIL defines these abstraction levels and the sandwich model including
all the priorities between different animations and different animation
types (attributeType), to put all this in the right order.
Because it defines the attributeType, additive behaviour, restarting issues 
etc, it has to define as well, how to stack all this together to one complex
sandwich (bon appetit! ;o)

>
> > If such a values is more complex like a colour value or that of an
> > svg:tranform, or lists of different lengths, the host language has to
> > define the interpretation of those constructs, as SMIL and SVG do for
> > colours, SVG for transform and for some complex list constructs like
> > stroke-dasharray (the animation value lists can have different length,
> > but because SVG defines how to interprete these lists as pattern, it is
> > possible to construct a representation, that is interpolable).
>
> Sure.
>
> >> And as a specific example to guide discussion, if you use SMIL to
> >> animate line-height, what should happen?
> >
> > This is a CSS property.
>
> Yes, indeed.  I'm largely interested in the attributeType="CSS" case,
> since that's what the discussion is about.
>
> > The CSS recommendation (or another using this property as well)
> > has to define whether this is animatable or not.
>
> Sure.  Say it is.  What should the behavior be when trying to animate it
> from "1" to "2", given that line-height accepts both numbers and lengths
> and they mean _different_ things?
>

In detail, we can have this choice:
normal | <number> | <length> | <percentage> | inherit
therefore here 2px is not the same as 2.
Well, this is an indication, that if this property is ever needed in SVG,
the SVG WG has to be pretty careful to avoid unintended nonsense ;o)
textArea from SVG tiny 1.2 has no such property, therefore currently
a problem outside of SVG ;o)

A solution could be for example to require to transform this
to some intrinsic line-height unit before animation and if required
do the presentation with an appropriate unit added again.
Obviously an author always has to use a unit for a length for this
property.

SMIL itself does not claim, that 2px is the same as 2.
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.
Without additional information from the host language, 
SMIL animation falls back to calcMode discrete, 
no continuous animation.
There is no built-in wisdom about what the values items
mean. This can be seen as an advantage too - if one 
manages to feed the SMIL animation machine with numbers 
or lists of numbers, the procedure inside is always the same
(for paced animations one has to feed some distance function
information as well).

In SVG the determination of the correct calcMode is already a 
problem with the overloaded fill and stroke properties. 
For something like values="black; yellow; red; url(#id);none" only
calcMode discrete is possible. And because these properties are
overloaded, the viewer has to analyse the values attribute carefully
to get the calcMode correct right from the begin of the animation,
because for many people it can be pretty important, that 
values="black; yellow; red" can result in a continuous animation
- an SVG specific problem - and it does not even need units for
some fun ;o)


Olaf

Received on Wednesday, 9 June 2010 18:26:40 UTC