I wish to clarify the expected behaviour of animations that are
dynamically removed and added from a document with regards to the
events that are generated.
Suppose an animation is in play when it is temporarily removed from
the document. Later, that same animation is re-attached to the
document. In the meantime however, the time of the document (or, more
accurately, the time container) may have changed either through
seeking the document or simply due to the wallclock time that has
When the animation is re-attached it must either catch-up or wind back
to the document time. However, just how this should be done is not, so
far as I know, specified.
Some options include:
1) When the element is removed, all information regarding the
animation's progress is lost. Re-attaching effectively performs a kind
of forwards-seek on the animation.
2) Animation progress is retained and when the element is re-attached
either a forwards or backwards seek is performed as required.
Personally, I think (1) is more intuitive, particularly as the element
may be re-attached to a different time container altogether.
However, regardless of which it is, there is still the question of the
nature of the seek. Generally, when seeking is performed most events
that would otherwise be generated along the way are suppressed. So,
is attaching an element a genuine seek in that sense or should all
events still be generated? My feeling is that they should still be
Thus for the attached example which I've simplified below:
document.addEventListener("SVGLoad", seek, true);
<animate begin="2s; 6s; 10s" dur="2s" id="animate" .../>
My understanding is that we should get:
* 1 x beginEvent as a result of the initial seek to t=11s (as per my
interpretation of )
* 2 x beginEvent as a result of re-attaching the animation element
(which will drive the animation through begin times 2s and 6s)
Then after 3s,
* 1 x beginEvent when the third interval begins (at t=10s)
Another issue is whether detaching an animation that is in play should
generate an endEvent. Personally I think it should not since otherwise
a lot of events would be generated on document teardown unless
implementations differentiate between these two situations
(script-based removal and document teardown).
Any thoughts here would be greatly appreciated.
add-remove.svg (1K) Download Attachment
On 8 okt 2010, at 02:45, Brian Birtles wrote:
> Dear all,
> I wish to clarify the expected behaviour of animations that are
> dynamically removed and added from a document with regards to the
> events that are generated.
I think you'll have to ask this in a more SVG-specific forum, at least: you'll be more likely to find people there who have an opinion on this for SVG, which seems to be your main interest.
For SMIL 2.0 we specifically allowed only very limited modification of the DOM tree (only adding begin times, really), because the semantics of modifying the live document on the fly are horrendous. At that time, we thought that a later incarnation of the SYMM group might tackle this, but so far that hasn't happened:-)
I'm personally rather interested in the subject of modifying active documents, and we've written a paper on preliminary work for Document Engineering this year, with the plan to work things out more thoroughly for next year. But so far the results are that allowing any random modification to an active document is probably out of the question, unless you're willing to recompute the whole timegraph, and even then describing the semantics of the changes will probably be (a) very difficult and (b) unexpected by end users. But the good news is that if you disallow some things (such as removing a node on which other nodes depend for their timing) it may be possible to come up with reasonable semantics. But, as said: the actual work still has to be done...
Jack Jansen, <[hidden email]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman
Thanks very much for your response.
On 11 October 2010 05:38, Jack Jansen <[hidden email]> wrote:
> I think you'll have to ask this in a more SVG-specific forum, at least: you'll be more likely to find people there who have an opinion on this for SVG, which seems to be your main interest.
Thanks, will do.
> For SMIL 2.0 we specifically allowed only very limited modification of the DOM tree (only adding begin times, really), because the semantics of modifying the live document on the fly are horrendous. At that time, we thought that a later incarnation of the SYMM group might tackle this, but so far that hasn't happened:-)
Right, there are some difficulties. However, if SMIL is to be part of
the Web platform I think this behaviour is important. It's hard on
developers when attempting to remove a <circle> from the DOM fails
just because it has an <animate> element hanging off it. Furthermore,
I can imagine editor-type applications wanting to create animated SVG
documents entirely via script.
So far our experience is that, while difficult, modifying live
documents is certainly achievable. SMIL already requires some facility
for recalculating intervals and propagating those changes to support
syncbase timing. We reuse some of that behaviour every time a
timing-related attribute is set on an animation element. We also use
an observer pattern to watch for ID changes and then update
dependencies, event registration etc. accordingly.
For the subset of SMIL available in SVG I think we have this working
reasonably well. But perhaps the difficulty arises when supporting
more general time containers and other SMIL features beyond SMIL
|Free forum by Nabble||Edit this page|