W3C home > Mailing lists > Public > www-svg@w3.org > October 2010

Re: Events when adding and removing SMIL animation elements in play

From: Brian Birtles <birtles@gmail.com>
Date: Fri, 15 Oct 2010 11:02:58 +0900
Message-ID: <AANLkTinG9EWaskgAdAyNsbAeCkEAV54Q9LnePHLdeNpH@mail.gmail.com>
To: Alex Danilo <alex@abbra.com>
Cc: www-svg <www-svg@w3.org>
Hi Alex,

Thanks for your comments here. They're very helpful. I need to go over
this again and reconsider all the implications but I just wanted to
check your final point here.

On 14 October 2010 09:29, Alex Danilo <alex@abbra.com> wrote:
> Most of your logic is OK, but you do need to remember that
> the seek is discontinuous and so intermediate intervals that
> get skipped on a seek should not generate any events cause
> they never ran.

Where is this specified?

Firstly, let me check I've understood correctly. Would you agree a
seek on a document (e.g. by calling svgElement.setCurrentTime) is

After all, if you set up a series of syncbase dependencies and then
perform a seek on the document the intervals DO run (but don't fire

As SMIL says:

  After seeking a document forward, the document should be in largely
the same state as if the user had allowed the presentation to run
normally from the current time until reaching the element begin time
(but had otherwise not interacted with the document). One exception
relates to event-based timing in the document, and is described

And again:

  If the presentation is authored with no beginEvent, endEvent or
repeatEvent based timing and no automatic hyperlinks, then state of
the document after a seek should be identical to that had the document
presentation time advanced undisturbed to reach the seeked-to time.[1]

So at least that kind of seek is continuous otherwise syncbase
dependencies would not be updated and the document would not be "in
largely the same state as if the user had allowed the presentation to
run normally".

However, if I understand correctly, you're saying that the seek
performed on an inserted element is a different kind of a seek: a
discontinuous seek.

However, my reading of SMIL's description of pruning vs cutting off
this sounds like more of an instance of cutting off.[2]

SMIL gives the example:

  <par begin="-10s" dur="20s">
   <img xml:id="slide1" src="slide1.jpg" dur="3s" />
   <img xml:id="slide2" src="slide2.jpg" begin="slide1.end+3s" dur="10s" />
   <img xml:id="note1" src="note1.jpg" begin="slide1.beginEvent" dur="20s" />

And in this case "slide1" is cut off. That is, it's not shown but it
does run in the sense of triggering "slide2". Isn't inserting an
element analogous to this?

e.g. if we have:

  <circle .../>
   <animate id="b" begin="a.begin+5s" ... />

And at t=5s we append another child element to the circle as such:

   <animate id="a" begin="1s" ... />

My expectation is that 'b' would get notified of the interval and
would run at t=6s even though 'a' would not be shown. That seems to me
to parallel the example from SMIL quoted above (and seems to make
intuitive sense too as if one seeks the document back to 0 and then
forward to 5 again the interval will certainly be created as per [1].
I realise event-based timing works differently in this case but SMIL
also makes it clear that event-based timing is special in this

I think intervals that are entirely <= 0 are a special case that SMIL
makes quite clear are invalid because they are before the parent
simple begin. Such intervals are filtered out of the model.

Intervals that merely precede the current time appear to be a
different case. The current time can change, even go backwards, the
parent simple begin cannot.

The issue of whether events fire in this case of inserting elements
still remains. You've mostly persuaded me they should NOT fire events
for these historic intervals (although I want to look over this once
more). However, I'm yet to be convinced the intervals don't run at

Thanks again Alex, looking forward to your feedback,


[1] http://www.w3.org/TR/SMIL/smil-timing.html#Timing-HyperlinksAndTiming
[2] http://www.w3.org/TR/SMIL/smil-timing.html#q89
Received on Friday, 15 October 2010 02:03:31 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:23 UTC