W3C home > Mailing lists > Public > www-smil@w3.org > January to March 2010

Re: Clarification of reset behaviour

From: Sjoerd Mullender <sjoerd@acm.org>
Date: Mon, 04 Jan 2010 11:37:43 +0100
Message-ID: <4B41C4F7.4010503@acm.org>
To: Brian Birtles <birtles@gmail.com>
CC: www-smil@w3.org
Brian Birtles wrote:
> Dear Jack and Sjoerd,
> 
> Thank you very much for your careful response to my queries. It is
> very helpful to know that I have understood the specification
> correctly on these points although I understand that the specification
> cannot be changed without producing a new version.
> 
> One issue which I would like to follow up is this final comment:
> 
> Sjoerd Mullender wrote:
>> Elements may begin without there being an end in sight.  This is
>> equivalent to having end="indefinite".  For animations this may be
>> problematic, however, since they often need some fixed duration over
>> which to change a value.
> 
> I don't think I quite understand what is being said here. In
> particular I would like to check my understanding of the condition
> given in the pseudocode for getFirstInterval[1] and getNextInterval[2]
> that if we have an end attribute specified we must match each begin to
> an end or else it's a bad interval. Therefore:
> 
>   <animate begin="1s; 3s" ... />
> 
> produces two intervals as no end attribute is specified. Whereas:
> 
>   <animate begin="1s; 3s" end="2s" .../>
> 
> produces only one interval since there is no end to match the begin at
> 3s  (and nor does the end attribute have event conditions or an empty
> end instance list). So I wonder if it's true that "elements may begin
> without there being an end in sight."
> 
> I bring this up here because (a) I might have misunderstood this and
> you may be able to correct me here, and (b) I suspect that in any case
> this pseudocode needs review. In particular the initial three lines:
> 
>    If there was no end attribute specified
>       // this calculates the active end with no end constraint
>       tempEnd = calcActiveEnd( tempBegin );
> 
> would effectively mean that any calls to endElement on an animation
> that lacks an end attribute would have no effect. However this seems
> counter-intuitive. A script should be able to stop an animation
> regardless of whether it has an end attribute specified.
> 
> (One suggestion for fixing this might be to change the first line to
> read "If there was no end attribute and there are no end instances.")
> 
> Again, this may be something for a later SYMM working group to consider.
> 
> Thank you once again for your helpful feedback on this.
> 
> Best regards,
> 
> Brian
> 
> [1] http://www.w3.org/TR/SMIL3/smil-timing.html#Timing-BeginEnd-LC-Start
> [2] http://www.w3.org/TR/SMIL3/smil-timing.html#Timing-BeginEnd-LC-End
> 

SMIL makes a difference between having and not having an end attribute.
 If you have an end attribute, you need a value for each begin, so in
your second example you could have

	<animate begin="1s; 3s" end="2s;indefinite" .../>

to get the two intervals.

When you call endElement() on an element with no end attribute, you
effectively add an end attribute, and the timing has to be recalculated
with that (virtual) end attribute.  See [1] where it says that each
endElement() call (and the other DOM calls) creates a single instance time.

I can't find an explicit mention of this, so I think this might be a
subject for an erratum.  It is certainly the intention that adding an
instance to a time list behaves as if the attribute comes into being, if
it wasn't there already.

[1] http://www.w3.org/TR/SMIL3/smil-timing.html#q88

-- 
Sjoerd Mullender


Received on Monday, 4 January 2010 10:38:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 4 January 2010 10:38:18 GMT