Re: Behaviour of animation DOM methods before document begin

On Fri, 16 Jan 2009 14:38:13 +0100, Jonathan Watt <jwatt@jwatt.org> wrote:

>
> On 1/15/09 11:14 AM, Erik Dahlström wrote:
>> On Thu, 15 Jan 2009 04:45:24 +0100, Brian Birtles <birtles@gmail.com> wrote:
>>>
>>> For SVGSVGElement.animationsPaused() can we assume that although animations
>>> are not playing prior to the document timeline begin, they should not be
>>> considered to be paused unless pauseAnimations() is called?
>>>
>>> SVG 1.1 says:
>>>
>>>   Returns true if this SVG document fragment is in a paused state.[2]
>>>
>>> Can we understand "a paused state" as being narrowly defined as "a paused
>>> state brought about by calling pauseAnimations()"? Or does it include the
>>> apparent paused state of an SVG document fragment because the document
>>> timeline has not yet begun?
>>
>> Since animations will play as soon as the document timeline starts it would seem a bit strange to return that the timeline is paused for this case.
>
> I agree. It's a shame that instead of 'animationsPaused()' we don't just have a
> 'timelineState' property with constants to represent "not yet begun", "running"
> and "paused" states.
>
>>> For SVGAnimationElement.BeginElementAt() what should be the behaviour if
>>> this is called prior to the document timeline begin since this is defined in
>>> terms of presentation time?[3] Shall we use the value of GetCurrentTime
>>> (which will be zero) and add an instance time with an offset from that? Or
>>> should the method fail?
>
> I think it could be desirable to allow animations to run before the document has
> loaded (and the timeline begun). 

Indeed, this feature was added in SVG Tiny 1.2, see http://www.w3.org/TR/SVGMobile12/struct.html#SVGElementTimelineBegin.

> The first example that comes to mind is a
> "Loading..." animation could be shown by a large document prior to it finishing
> downloading. As a consequence of this, I don't think we would necessarily want
> to define the timeline as being paused until the document has finished loading
> (in reference to your first question).
>
> As an aside on 'getCurrentTime()', perhaps it should return some number to
> indicate "not yet defined" rather than zero. NaN?

See http://www.w3.org/TR/SVGMobile12/svgudom.html#svg__SVGSVGElement_getCurrentTime.

>> The question can be reformulated:
>> If one calls 'beginElement' on some animation element before the document timeline has started, will the animation run once the timeline starts?
>
> Or can it start immediately, and the implementation can keep track of time until
> the document timeline starts? (At which point it can fix up the times of
> animations that have already started to be relative to the document start time
> (negative).) Personally that seems desirable to me to allow animation to work
> while large SVGs load so that users get a better user experience. For example,
> while a map with complex overlays loads the user could be interacting with the
> animated interface to configure it for when the overlays complete.

See http://www.w3.org/TR/SVGMobile12/svgudom.html#smil__ElementTimeControl.

> I'm not sure what burden this would put on implementers at this point, or how
> feasible it would be to have this behavior given the current spec. I'm still
> getting back up to speed on both. Worth considering though?

I think that letting the document timeline start before onload isn't something we can reasonably claim is not a new feature, and thus it wouldn't qualify for the 1.1 errata. However, implementations that do 1.2T would be able to do this, if the 'timelineBegin' attribute was set to 'onStart'.

Cheers
/Erik

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Friday, 16 January 2009 13:56:34 UTC