Re: [css3-transforms] <transform-list>

Dirk Schulze:

...
> > Of course. Therefore if a string appears as a value
> > without further explanation, calcMode discrete has to used as default.
>
> IIRC, you saw a problem with not defining the additive behavior on CSS3
> Transforms. Could you look at the new section "The 'animate' and 'set'
> element" [1] please? Is it sufficient? Am I missing something?

The letter combination <transform-list> should of course refer to the
paragraph, that defines, what it is ;o)
This is the paragraph in the same section 14.1 starting with
"With this specification the SVG basic data type <transform-list> is 
equivalent is equivalent to a list of <transform-function>s."
To know, what <transform-function> is, one needs a reference
to a definition of <transform-function>, I think, this is defined
in section 15. In the following I assume you add references/links
to get this chain.

An example for a <transform-list> 
would be "scale(1,-1) translate(-100,100) skewX(17)"
therefore an example for a values list of those types is
values="scale(1,-1) translate(-100,100) skewX(17);  skewY(-37); rotate(42) 
scale(-1,1)"

Indeed section 14.1 defines the behaviour for animation as:
"SVG animations must run the same animation steps as described 
in section Transitions and Animations between Transform Values."
-> Maybe better 'SVG animations using the element animate'?
You don't have an interpolation problem for set and for
animateTransform you have specific rules, because it specifies
the type of transformation explictly, to avoid all these complications,
which are referenced to and described in section '17.  Interpolation of 
Transforms.'
It still has the problem to use the unfortunate words from and to, 
beeing identical with SVG/SMIL attributes of a specific meaning, 
to continue here to understand something, one has to forget these 
words and one has to assume, that it talks about two consecutive 
values of a values list - this needs to be fixed of course, as already
discussed.

As far as I understand this section 17, one can derive for arbitrary
consecutive values of <transform-list>s corresponding lists of numbers,
that can be interpolated somehow, sometimes the simple
way, sometimes using the decomposition method to get
other lists of numbers, which can be interpreted
again as <transform-list>s, that can be converted again
in lists of numbers, which can be interpolated depending
on the calcMode, discrete as well as linear or spline,
including additive or not additive behaviour.

This applies as long as there are no exceptions, that
suddenly change the interpolation behaviour, because
the calcMode applies for the complete values attribute, 
not just for two consecutive values (this is often 
implemented wrong currently in many SVG viewers).
But as far as I understand this, there is no such 
sudden change. Basically 'only' the number of list
items and there meaning may change - if implementors
have no problem with such a complication - why not?
There has been a lot of resistance to implement much
simpler things ;o)
This requirement for interpretation of numbers 
(beyond one distance function for paced for the
complete values list) is new for this construction and the 
complexity is beyond the simple structures assumed in 
SMIL, even beyond the list complexity of some properties or
attributes in SVG, where the length of such lists
can change as well, at least for those the meaning
of the numbers remain - my guess is, that even this is 
already a source of implementation bugs/problems. 

I think, if someone has already a  complete 'SMIL' machine, 
a new modul is required as extension, because one
needs a look-up for each pair of consecutive
values, what the numbers mean instead of
simply calculating the complete animation effect.
Respectively one has to calculate two different sets
of number lists with different meaning for one value
in the values list.
With the core SMIL animation idea, I think this is
incompatible and far too complex, but SVG has
already a few exceptions and extensions for 
animateTransform and animateMotion. 
And it has already the overloaded attributes
like fill and stroke, causing problems for
animation in most viewers.
There were already rumors, that SMIL
animation is difficult to implement, and the
bugs in viewers for the already existing exceptions and 
extensions in SVG indicate even more problems -
therefore we don't have to worry about yet another
complication ;o)
The current and previous SVG recommendations avoid 
such complications, allowing only type specific animations
with animateTransform to be as compatible as 
possible with the simple SMIL approach, I think,
this was very well thought-out. This extension
promises a lot of bug-searching-fun for everyone - 
implementors, authors, the audience ;o)


Because for most of the complex lists there is no
meaningful distance function available, there is no
calcMode paced defined/possible.
If it is assumed, that authors wanting to use animate
animations of this approach will never want to use paced
behaviour, this looks ok for the element animate.
However at least if an author uses only translations
(2D as well as 3D), paced animation can be quite useful
to get similar behaviour as for animateMotion with its
default calcMode paced. To get this, an author still
either has to
a) use animateMotion for 2D
b) use animateTransform of type translate with calcMode paced
    (for 3D one still has to mention at least the Euclidian distance,
    else this option is excluded as well)
c) calculating the timing (keyTimes) manually


To resume, if you close the 'logical chain' with some references,
that readers don't have to use the search option of a browser
to understand the text, I think with this text it is possible to
get continuous and additive animation effects - but only
if the simple SMIL concept is extended with such a complex
additional model for just one value/property.



Olaf


> [1] http://dev.w3.org/csswg/css3-transforms/#svg-animate-element

Received on Sunday, 3 June 2012 16:48:32 UTC