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

RE: Duration of an SVG file

From: Michael Curtes <michael@faithwestinc.com>
Date: Tue, 8 Jul 2008 08:52:38 -0700
Message-ID: <B832B5B0B0587E4580BAD8E8E6A835BD0106524B@fw7.faithwestinc.com>
To: <www-svg@w3.org>

Hi Julien,

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.

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?

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.


-----Original Message-----
From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf
Of Julien Reichel
Sent: Tuesday, July 08, 2008 8:42 AM
To: Dr. Olaf Hoffmann; www-svg@w3.org
Subject: RE: Duration of an SVG file


> But you can set the dur attribute on the animation element.

Indeed, you can also set the dur for a video element, but also use the
media duration when the duration of the video file is not known in
advance. The same principle apply for animated SVG, you can use the dur
on the <animation> element, but there are (many?) cases where you would
like to defer the computation of the duration to the person that create
the svg animation. In this case using <animation dur="media" ...> is
very handy.
> Why it is required to have this for the svg element?

I would not say it is required, it is more a logical add-on which would
allows you to work with SVG animation the same way you would work with
other media (especially video). Using today's SVG specification you are
forced to use a different way to control the time of an included clip
depending on it's type (video or SVG animation).

> SMIL has time containers and this would be nice too for 
> example for SVG 1.2 to be more flexible, but this is maybe to 
> much for a tiny profile.

Well, you are probably going beyond my request with the SMILE
containers, but in a rough manner the <svg> element could be seen as a
(tiny?) version of the containers. 

> > For this reason we have added a non-standard way to specify the 
> > duration of an SVG file by supporting the attribute dur to 
> the <svg> element.
> >
> If you really need a proprietary attribute I would like to 
> suggest to use a separate namespace for it as long as this is 
> not part of an SVG specification, for example:

Actually we are using a separate namespace
xmlns:spx="http://www.spinetix.com/namespace/1.0/spx". I just simplified
the explanation in my previous mail to avoid very long lines.
> But maybe you can convince the SVG working group to adopt dur 
> for svg too, but for many documents containing animation I 
> wrote, the duration would be still indefinite or in some 
> cases the time until it repeats is larger than the life time 
> of any computer.

This was the logic behind the attribute dur on the <svg> element. If not
present (which is the case of most svg files) then the duration is
indefinite. It's only when the creator of the SVG animation wants an
explicit duration for its clip that the "dur" attribute becomes useful.
Adding a specification for the dur attribute doesn't break the backward
compatibility with any existing document.

I would be happy to try to "convince the SVG working group to adopt dur
for svg too". That was the one of the purpose of this email :-)


Visit http://www.spinetix.com/ for more information 
Received on Tuesday, 8 July 2008 18:36:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:19 UTC