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

RE: Duration of an SVG file

From: Andrew Emmons <andrew.emmons@quickoffice.com>
Date: Wed, 9 Jul 2008 15:00:49 -0500
To: Julien Reichel <Julien.Reichel@spinetix.com>, Michael Curtes <michael@faithwestinc.com>, "www-svg@w3.org" <www-svg@w3.org>
Message-ID: <A13D0B44629697468E9C6AE200CFD39A524E3D4F5E@mailkeeper.mdigitalm.com>

Hello,

> -----Original Message-----
> From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf
> Of Julien Reichel
> Sent: Tuesday, July 08, 2008 5:39 PM
> To: Michael Curtes; www-svg@w3.org
> Subject: RE: Duration of an SVG file
>
>
> Hi Michael,
>
> > I agree that it might be convenient to quickly be able to
> > identify the point at which SVG content has finished any and
> > all animations. But I don't know that everyone would agree
> > that if SVG content does not have your proposed dur attribute
> > 'then the duration is indefinite'. I know of at least one
> > popular mobile SVG UA that logically determines when the last
> > time-based event has finished and then considers the content
> > to have ended.


The UA Michael is kindly referring to is the BitFlash SVG player.
>
> Then this ambiguity should be removed from the SVG specification. I
> agree with Olaf, that according to the current specification including
> an animation in another document using the <animation dur='media'
> repeatCount='2' ...> should cause the animation never to repeat.
>
> If on the other hands the duration of an SVG animation is the position
> of the last time-based animation, this is also a good solution (more
> complex). But in either case this should be clearly specified.
> (As a note we actually also determine the duration of an SVG as the
> last
> time based event in case the attribute dur='media', but I considered
> that to be a too complex change to the SVG specification to be proposed
> at that time )

We share that concern which is one reason why this solution was never proposed, at least by us.

>
> > I also think that adding a dur attribute to the svg element
> > could potentially have complicated implications for UA's. For
> > example, what should the UA do when rendering content in
> > which specific animations are written to continue beyond the
> > dur of the svg element? Should it stop the content at the
> > point of a dur clock-value or continue until the last
> > animation has finished?
>
> If we consider the attribute dur to be a subset of the SMILE containers
> [1], then the answer to your question is that the UA should stop the
> animation at the end of the duration (dur) of the SVG files. At least
> that would be my understanding. Continuing until the last animation has
> finished would make the specification of a dur attribute completely
> useless.
>

If the svg file is being played from within an <animation> element, I agree with you.

> How does you UA behave when an SVG with the last time-based event occur
> at 15s is included into another document using the an <animation
> dur='10s' repeatCount='2' > ?
>

It would end the svg file at dur=10s.

>
> > I think it's great that you've come up with a solution that
> > works for your work and I think proposing modifications to
> > the spec is only a good thing. It gives us all a chance to
> > debate something.
>
> Actually learning that other UA are facing the same problem of SVG
> duration comfort me in my opinion that something should be done for
> this
> subject. If some UA are computing an automatic duration for SVG files
> and other are considering the file to be of infinite duration this will
> make it very difficult for user to create content that can be displayed
> in the different UA.

We have found it depends on the use case. For you and some of our customers, one may want to know the dur of the SVG file. However, for a generic SVG player, or one heavily using user interaction and scripting in content, knowing the 'dur' of the top-level SVG is not only impossible but it also has no meaning. At any time user interaction, timer events, AJAX, etc could come in and change the content, start an animation, etc.  To us, this was more of an implementation detail than an issue with the SVG language.

All the best,
Andrew
Received on Wednesday, 9 July 2008 20:02:45 GMT

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