>From what I understand from the spec, these "to" animations should
operate as follows:
1) a1 starts when the rect is moused over
2) a2 starts when the rect is moused out
3) a1 finishes at whatever happens first:
- when moused out or
- 4 seconds after the rect is moused over
4) a2 finishes at whatever happens first:
- when moused in or
- 4 seconds after the rect is moused out
5) the presentational (underlying?) value of the rect's width is
frozen when either animation is finished
6) when either animation starts, the "underlying" value is used as a
Are all of the above true?
The behavior I'm experiencing (on Opera 9.5, that is) is as follows:
Time 0s: mouse into the rect (width="300" and it starts growing)
Time 3s: mouse out of the rect (width="600" and it starts shrinking)
Time 5s: mouse into the rect (width jumps to 300 and starts growing)
It's the "jumping" part that doesn't seem right to me. I think upon
the second mouse-in that the animation should start at whatever its
current presentational/underlying vlaue is (450 in this case).
Batik 1.7 is even worse (it doesn't freeze values). Can anyone
clarify for me what the behavior should be?
I think, your interpretation of the SMIL to animation is correct so far,
because the behaviour is defined to different from all the other
types of animations due to this specific rule for the frozen value.
However I have not seen any user agent so far with a complete correct
implementation of to animations in SVG so far.
Therefore with such more complicated cases - whatever you currently
see - has a big chance to be nonsense ;o)
Therefore currently it is only useful to write test cases (and to fix
errors in implementations of course), not to use to animations in
'real world' documents ...
I have several tests for to animations written - results are typically