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

Hi Olaf,

On Jun 3, 2012, at 9:48 AM, Dr. Olaf Hoffmann wrote:

> 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.
Yes, a link would help. I'll add links.

> 
> 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)"
Adding more examples sounds like a good idea.

> 
> 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'?
Yes.

> 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.'
Exactly.

> 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.
This section defines interpolation for a starting value and an end value, independent if these are values in a list of values (like for the 'values' attribute). Maybe the word 'source-' and 'destination-transform' could help here?

> 
> 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 behavior.
Sounds complicated, but yes :).

> 
> 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).
No, that is what the SVG error handling section wants from the viewer. I already added a comment to my previous mail about that.

""
If the document has animations, the animations shall stop at the point at which an error is encountered and the visual presentation of the document shall reflect the animated status of the document at the point the error was encountered.
""

> 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)
Th sudden change could be scripting. But this needs to get handled by viewers supporting scripts anyway.

> 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 don't believe so. The behavior on CSS Animation is not that different on SMIL here and I couldn't see any differences between implementations there so far.

> 
> 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.
Both are extensions for SMIL Animation. It is indeed new, that you can animate complete transform-lists. But that works on CSS already. And the specification defines it for SVG Animation the same way.

> And it has already the overloaded attributes
> like fill and stroke, causing problems for
> animation in most viewers.
Might be, but not an issue that needs to be discussed for this spec.

> 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)
I don't really worry about this here. I don't think that the SVG Animation part is the difficult thing to implement. It is more the SVG DOM part, now that 'transform' is a presentation attribute. The calculations for SVG animation don't differ to CSS Animation. The biggest difference is the additive behavior controlled but 'additive' attribute. And it is specified how to do this in CSS Transforms (basically the same way as for 'animateTransform').

> 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)
Every new implementation brings bugs. If we worry about these first days, we shouldn't start specifying anything.

> 
> 
> 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
Not sure about c), but indeed, 3D translation sounds like a good use case for paced animations on 'animate'.

> 
> 
> 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.

Thanks you very much for your feedback! I try to address your concerns as good as possible.

Greetings,
Dirk

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

Received on Monday, 4 June 2012 16:45:30 UTC