W3C home > Mailing lists > Public > www-svg@w3.org > July 2008

Re: Question about animate-elem-201-t

From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
Date: Fri, 11 Jul 2008 20:03:34 +0200
To: "Julien Reichel" <Julien.Reichel@spinetix.com>, www-svg@w3.org
Message-Id: <200807112003.35259.Dr.O.Hoffmann@gmx.de>

Julien Reichel:
> Ok, I got your point ( I still need more to be convinced :-) )
> So let me consider the attached example (also copied at the end of the
> mail in case the mailing list doesn't let it trough)

Nice Opera-killer (Opera 9.50/9.51 crash immediately,
reason seems to be the set inside desc ;o)

> According to your explanation, all 4 square should stay green all the
> time. Is it correct ?

desc cannot contain set - therefore it is difficult to explore whether the
set can be used as a syncbase. I think, there is no specific rule in 
SVGT1.2 to cover such a case, it is only noted in C.2 that is not rendered,
no problem for a set element, but this does not indicate whether it has
to be interpreted or not.

The first and third rect animation has to wait for the syncbase. 
And even if it happens, there will be no visible effect, because there 
is no fill freeze.
If there is a syncbase at 0, this creates an intervals [-2s,0) therefore
before the document time, this has to be ignored and cannot be used
for anything.
If there is a syncbase at 4s, this creates an interval [2s,4s) at 4s,
too late to be visible, but can be used as another syncbase.

For the second and fourth the end values list is empty at 0 if the syncbase 
is not interpreted, this means fill switches to blue/red until there is an 
end, because there is no dur attribute.
At 2s it switches again to blue/red, if the syncbase is not interpreted,
because it is already blue/red this creates no further difference.
If the syncbase happens at 0, this creates an empty/invalid interval,
the animation does not start.
The end value of 0 is still in the list at 2s, the restart is not possible.
The restart of syncbase at 4s replaces the end value and this
creates the interval [2s,4s) at 4s, to late for a visble effect, but
can be used as another syncbase.

> However, if we considerer that the timeline is build on opening the
> document, 

This can be set by the attribute timelineBegin = "onLoad" | "onStart" 
in SVGT 1.2, the default is 'onLoad', to be used here.

> the 2 square on the left should change to blue after 2 
> seconds. The two square on the right should never change to red, as the
> beginEvent is incontestably trigged only when it happens. Is my testset
> correct ?

This might cause problems and fixes, if you have a begin list for the
syncbase like:
begin="4s; click; someOther.activate; resize; scroll; zoom; rotate; focusout; 

And maybe some DOM manipulations may appear too, setting a new begin.
If the simple offsets like 4s and 60s are already used to setup other
begin/end lists, sometimes it can be wrong to start an animation due to
these values if something different happens. But with negative offset
combined with syncbase values this might result in an animation, that
has already been started, before the new events create a situation, 
where the animation should have never been started.
This would require more rules what to do with such invalid animation
starts. This is not available in SMIL, maybe because this gets too
Maybe this is more a question to ask in the mailing list of the 
SYMM working group, responsible for SMIL.

> Now, if that is correct it means that using negative offset in bend or
> end attribute will not let you start an action before the trigger
> actually happens. So for instance if I want to trig a fly out on a video
> object writing something like:
> <video xml:id='videoid' ...><animate attributeName='x' from='0' to='200'
> dur='1s' begin='videoid.end-1s'</video>
> It will not cause the video to fly to the right at the last second.
> Is it correct ?

Yes, I think so (maybe I still have to look, if I fixed all my
tests related to this ;o)

> If yes, then this is very inconvenient.

Sure, for simple offset values this is something nasty, but if
it gets more complex, it might get impossible to implement
it including a prediction of what a user might do within the
active duration of the document or requires sniffing into scripts,
what might happen within the active duration of the document.

> In this case I do not really understand the difference between
> 'id.begin' and 'id.beginEvent'. But I believe this is the subject of
> another email on another mailing list :-)

Yes, currently the main difference seems to be, that accidently (?)
beginEvent and endEvent are indicated to bubble in SVGT 1.2, while 
all SMIL specifications note, that they do not bubble, what looks more
useful from my point of view ...

> All the best
> Julien
> <?xml version="1.0" encoding="UTF-8"?>
> <!-- Generator: SpinetiX Hyper Media Director -->
> <svg xmlns="http://www.w3.org/2000/svg"
> xmlns:xlink="http://www.w3.org/1999/xlink" dur="6" height="100%"
> viewBox="0 0 800 600" width="100%" xml:id="svg">
>  <desc>
>   <set attributeName="display" begin="0;4" to="inherit"
> xml:id="syncbase"/>
>  </desc>

desc? <-> defs?

>  <rect fill="green" height="200" width="200" x="100" y="50">
>   <set attributeName="fill" begin="syncbase.begin-2s" dur="2s"
> to="blue"/>
>  </rect>

>  <rect fill="green" height="200" width="200" x="100" y="300">
>   <animate attributeName="fill" begin="0;2s" end="syncbase.begin"
> values="blue"/>
>  </rect>

>  <rect fill="green" height="200" width="200" x="500" y="50">
>   <set attributeName="fill" begin="syncbase.beginEvent-2s" dur="2s"
> to="red"/>
>  </rect>

>  <rect fill="green" height="200" width="200" x="500" y="300">
>   <animate attributeName="fill" begin="0;2s" end="syncbase.beginEvent"
> from="red" to="red"/>
>  </rect>

>  <rect height="50" x="0" y="550">
>   <animate attributeName="width" dur="6" from="0" to="800"/>
>  </rect>
> </svg>

Caution: backwards incompatibility with SVG 1.1 versions of viewers, for
SVG 1.1 'width' is a required attribute for rect. And this document does
not even indicate, which version/profile is used.
Received on Friday, 11 July 2008 18:10:30 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:39 GMT