W3C home > Mailing lists > Public > www-smil@w3.org > October to December 2010

Re: Events when adding and removing animation elements in play

From: Brian Birtles <birtles@gmail.com>
Date: Tue, 12 Oct 2010 09:17:19 +0900
Message-ID: <AANLkTikmG_JLFX6OO6_DcGWOUAdOo6xXAgXsc0drzm8J@mail.gmail.com>
To: Jack Jansen <Jack.Jansen@cwi.nl>
Cc: www-smil@w3.org
Hi Jack,

Thanks very much for your response.

On 11 October 2010 05:38, Jack Jansen <Jack.Jansen@cwi.nl> wrote:
> Brian,
> 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

Best regards,

Received on Tuesday, 12 October 2010 00:17:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:28 UTC