Re: SVG12: Manipulation of animation elements

Without arguing about clarity of the spec, I should point out that you seem 
to think of SMIL animation as something different from what it is. Timing 
elements (including animation) do not "execute", rather they are "laid out" 
on time axis in much the same way as geometrical elements are laid out on x 
and y.


At 07:35 PM 1/8/2005 +0100, Bjoern Hoehrmann wrote:

>Dear Scalable Vector Graphics Working Group,
>   From and any of its
>dependencies it seems unclear how manipulation of animation elements
>must be handled by SVG 1.2 implementations. The following SVG 1.2
>document demonstrates what I believe is a bug in the Adobe SVG Viewer
>6.0 Build 38363,
>   <svg
>     xmlns               = ""
>     version             = "1.2"
>   >
>   <text y = '100' font-size='50'>
>     <tspan>Scalable Vector Graphics</tspan>
>     <animate
>        begin            = '0s'
>        attributeType    = 'CSS'
>        attributeName    = 'opacity'
>        from             = '0'
>        to               = '1'
>        dur              = '2s'
>        fill             = 'freeze'
>        id               = 'c'
>     />
>   </text>
>   <script type="text/ecmascript">
>   <![CDATA[
>     var node = document.getElementById('c');
>     node.setAttributeNS(null, "begin", "2s");
>   ]]>
>   </script>
>   </svg>
>For this example, the viewer will execute an animation that does not
>exist when the document begins (the animation in the <animate> element)
>and the animation that exists in the document tree after executing the
>script. Assuming that this behavior is conforming, one would expect that
>after replacing begin='0s' by begin='4s' "both" animations would still
>be executed just delayed by 2 seconds. This is however not the case, the
>viewer will only consider the animation that begins at 2s. If the "two"
>animations overlap, the viewer will restart the animation with the new
>parameters provided by the script. With begin='0s' and the <script>
>element replaced by
>   <script type="text/ecmascript">
>   <![CDATA[
>     var node1 = document.getElementById('c');
>     var node2 = node1.cloneNode(false);
>     node2.setAttributeNS(null, "begin", "1s");
>     node1.parentNode.replaceChild(node2, node1);
>   ]]>
>   </script>
>the effect is that "both" animations start at their corresponding begin
>where the "second" animation restarts the animation but it ends with the
>end of the first animation such that you end up with half-opaque text.
>Strangely, if the animate element is removed via scripting no animation
>is executed.
>The behavior I expect is that processing of animation elements in the
>document tree starts when the document begins such that elements that
>are not in the document tree at that moment are not considered, etc. I
>could not find any clear requirements in the SVG 1.2 Working Draft or
>its dependencies that requires the behavior I expect or that supports
>the behavior of the Viewer I've mentioned.
>Thus, please change the SVG 1.2 Working Draft such that it clearly re-
>quires the behavior I expect and include proper test cases for this re-
>quirement in the SVG 1.2 test suite.
>Furthermore, the Second Edition of the SMIL 2.0 Recommendation states
>in that
>specifications should limit manipulation of animation elements after
>the document has begun and make certain other restrictions. It seems
>that the SVG 1.2 Working Draft does not satisfy these requirements,
>please change the SVG 1.2 Working Draft such that it satisfies these
>requirements, or such that it notes why it does not satisfy them and
>defines all relevant processing.
>Finally, the requirements for processing animation elements that are
>dynamically added after the document has begun is not clear to me. It
>is for example not clear to me whether such an element begins relative
>to the document begin or relative to the current presentation time. I
>would expect them to begin relative to the current presentation time
>but it seems easy to argue the other side and even think that such an
>animation would not begin at all. Please change the SVG 1.2 Working
>Draft such that this is clearly defined.
>If any of this happens to be unclearly defined already, please change
>the SVG 1.2 Working Draft such that this is more obvious, for example
>by an informative section that refers to the normative requirements.
>Björn Höhrmann · ·
>Weinh. Str. 22 · Telefon: +49(0)621/4309674 ·
>68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 ·

Received on Saturday, 8 January 2005 20:51:14 UTC