SMIL 1.0 solved fundamental media synchronization problems and defined a powerful way of choreographing multimedia content. SMIL Boston extends the timing and synchronization support, adding capabilities to the timing model and associated syntax. This section of the document specifies the Timing and Synchronization module.
There are two intended audiences for this module: implementers of SMIL Boston document viewers or authoring tools, and authors of other XML languages who wish to integrate timing and synchronization support. A language with which this module is integrated is referred to as a host language. A document containing SMIL Timing and Synchronization elements and attributes is referred to as a host document.
As this module is used in different profiles (i.e. host languages), the associated syntax requirements may vary. Differences in syntax should be minimized as much as is practical. The semantics of the timing model and of the associated markup must remain consistent across all profiles. Any host language that includes SMIL Boston Timing and Synchronization markup (either via a hybrid DTD or schema, or via namespace qualified extensions) must preserve the semantics of the model defined in this specification.
Some SMIL 1.0 syntax has been changed or deprecated. Only SMIL document players must support the deprecated SMIL 1.0 attribute names as well as the new SMIL Boston names. A SMIL document player is an application that supports playback of SMIL Language documents (i.e. documents with the associated MIME type "application/smil").
This section is informative.
SMIL Timing defines elements and attributes to coordinate and synchronize the presentation of media over time. The term media covers a broad range, including discrete media types such as still images, text, and vector graphics, as well as continuous media types that are intrinsically time-based, such as video, audio and animation.
Three synchronization elements support common timing use-cases:
These elements are referred to as time containers. They group their contained children together into coordinated timelines.
SMIL Timing also provides attributes that can be used to specify an element's timing behavior. Elements have a begin, and a simple duration. The begin can be specified in various ways - for example, an element can begin at a time, based upon when another element begins, or when some event (such as a mouse click) happens. The simple duration defines the basic presentation duration of an element. Elements can be defined to repeat the simple duration, a number of times or for an amount of time. The simple duration and any effects of repeat are combined to define the active duration. When an element's active duration has ended, the element can either be removed from the presentation or frozen (held in its final state), e.g. to fill any gaps in the presentation.
Figure 1 illustrates the basic support of a repeating element within a simple par time container. The corresponding syntax is included with the diagram.
<par begin="0s" dur="33s"> <video begin="1s" dur="10s" repeatCount="2.5" fill="freeze" .../> </par>
Figure 1 - Strip diagram of basic timing support. The starred "Simple*" duration indicates that the simple duration is partial (i.e. it is cut off early).
The attributes that control these aspects of timing can be applied not only to media elements, but to the time containers as well. This allows, for example, an entire sequence to be repeated, and to be coordinated as a unit with other media and time containers. While authors can specify a particular simple duration for a time container, it is often easier to leave the duration unspecified, in which case the simple duration is defined by the contained child elements. When an element does not specify a simple duration, the time model defines an implicit simple duration for the element. For example, the implicit simple duration of a sequence is based upon the sum of the active durations of all the children.
Each time container also imposes certain defaults and
constraints upon the contained children. For example in a
<seq>, elements begin by default right after
the previous element ends, and in all time containers, the active duration
of child elements is constrained not to extend past the end of the
time container's simple duration. Figure 2 illustrates the effects of a repeating
<par> time container as it constrains a
<video> child element.
<par begin="0s" dur="12s" repeatDur="33s" fill="freeze" > <video begin="1s" dur="5s" repeatCount="1.8" fill="freeze" .../> </par>
Figure 2 - Strip diagram of time container constraints upon child elements. The starred "Simple*" durations indicate that the simple duration is partial (i.e. it is cut off early).
The SMIL Timing Model defines how the time container elements and timing attributes are interpreted to construct a time graph. The time graph is a model of the presentation schedule and synchronization relationships. In an ideal environment, the presentation would perform precisely as specified. However, various real-world limitations (such as network delays) can influence the actual playback of media. How the presentation application adapts and manages the presentation in response to media playback problems is termed runtime synchronization behavior. SMIL includes attributes that allow the author to control the runtime synchronization behavior for a presentation.
The SMIL Timing and Synchronization syntax and precise semantics are described in the following section. A set of symbols are used in the semantic descriptions:
B
d
AD
AE
The timing model is defined by building up from the simplest to the most complex concepts: first the basic timing and simple duration controls, followed by the attributes that control repeating and constraining the active duration. Finally, the elements that define time containers are presented.
The time model depends upon several definitions for the host document: A host document is presented over a certain time interval. The start of the interval in which the document is presented is referred to as the document begin. The end of the interval in which the document is presented is referred to as the document end. The difference between the end and the begin is referred to as the document duration. The formal definitions of presentation and document begin and end are left to the host language designer (see also "Required host language definitions").
This section defines the set of timing attributes that are common to all of the SMIL synchronization elements.
@@ Need to define "local time" or find a different term.
The basic timing for an element is described using the begin
and dur attributes. Authors can specify the begin time of an
element in a variety of ways, ranging from simple clock times to the time
that an event (e.g. a mouse-click) happens. The simple duration of an element
is specified as a simple time value. The length of the simple duration is
specified using the dur attribute. The attribute syntax is described
below. The normative syntax rules for each attribute value variant are described
below (in Timing Attribute
Values); a syntax summary is provided here as an aid to the reader.
<seq> time container.
If no begin is specified, the default timing is dependent upon
the time container. Children of a <par> begin by default
when the <par> begins (equivalent to
begin="0"). Children of a <seq> begin by
default when the previous child ends its active duration (equivalent to
begin="0"). Children of an <excl> default
to a begin value of "indefinite".
The begin value can specify a list of times. This can be used to specify multiple "ways" or "rules" to begin an element, e.g. if any one of several events is raised. A list of times can also define multiple begin times, allowing the element to play more than once (this behavior can be controlled, e.g. to only allow the earliest begin to actually be used - see also Restarting elements).
In general, the earliest time in the list determines the begin time of the element. In the case where an element can begin multiple times, the next begin time is the earliest begin time after the current time. There are additional constraints upon the evaluation of the begin time list, detailed in Evaluation of begin and end time lists.
If there is an error in any individual value in the list of begin values,
only the individual value will be ignored (as though it were not specified),
but the rest of the list will not be invalidated. If no legal value is specified
in the list of begin values, the default value for begin will
be used.
When a begin time is specified as a syncbase variant, a marker value or a wallclock value, the defined time must be converted by the implementation to a time that is relative to the parent time container (i.e. to the equivalent of an offset value). This is know as timespace conversion, and is detailed in the section Converting between local and global times.
If there is any error in the argument value syntax for dur ,
the attribute will be ignored (as though it were not specified).
If the element does not have a (valid) dur attribute, the simple
duration for the element is defined to be the implicit duration of the element.
The implicit duration depends upon the type of an element. The primary
distinction is between different types of media elements and time containers.
Note that if a media element has time children (e.g. animate
or area elements), then it is also a
<par> time container. If the media element has no time
children, it is described as a simple media element.
clipBegin and clipEnd attributes on a
media element can override the intrinsic media duration, and will define
the implicit duration. See also the Media Object module.
<seq>, <par> and
<excl> time containers, including media elements that
are also time containers, the implicit simple duration is a function of the
children of the time container. For details see the section
Time container durations.
If the author specifies a simple duration that is longer than the "intrinsic" defined duration for a continuous media element, the ending state of the media (e.g. the last frame of video) will be shown for the remainder of the simple duration. This only applies to visual media - aural media will simply stop playing.
Note that when the simple duration is "indefinite", some simple use cases can yield surprising results. See the related example #4.
Note that when the begin attribute refers to an event, or to
the begin or active end of another element, it may not be possible to calculate
when the begin will happen. For example, if an element is defined to begin
on some event, the begin time will not be known until the event happens.
When such a time becomes known (i.e. when it can be calculated as a presentation
time), the time is said to be resolved (see also the discussion
of Unifying scheduled and interactive
timing).
The following example shows simple offset begin timing. The
<audio> element begins 5 seconds after the
<par> time container begins, and ends 4 seconds later.
<par> <audio src="song1.au" begin="5s" dur="4s" /> </par>
The following example shows syncbase begin timing. The
<img> element begins 2 seconds after the
<audio> element begins.
<par> <audio id="song1" src="song1.au" /> <img src="img1.jpg" begin="song1.begin+2s" /> </par>
Elements can also be specified to begin in response to an event. In this example, the image element begins (appears) when the user clicks on element "show". The image will end (disappear) 3 and a half seconds later.
<text id="show" ... /> <img begin="show.click" dur="3.5s" ... />
In the syntax specifications that follow, allowed white space is indicated as "S", defined as follows (taken from the [XML10] definition for "S"):
S ::= (#x20 | #x9 | #xD | #xA)*
A begin-value-list is a semi-colon separated list of timing specifiers:
begin-value-list ::= begin-value (S";"Sbegin-value-list )? begin-value ::= (offset-value | syncbase-value | syncToPrev-value | event-value | media-marker-value | wallclock-sync-value)
An end-value-list is a semi-colon separated list of timing specifiers:
end-value-list ::= end-value (S";"Send-value-list )? end-value ::= (clock-value | syncbase-value | syncToPrev-value | event-value | media-marker-value | wallclock-sync-value)
Several of the timing specification values have a similar syntax. In addition,
XML ID attributes are allowed to contain the dot '.' separator
character. The backslash character '\' can be used to escape the dot separator
within identifier and event-name references. To parse an individual item
in a value-list, the following approach defines the correct
interpretation.
'+' or '-'), the value should be parsed as an
offset value.
.'
separator characters preceded by a backslash '\' escape character.
.' separator character, then the value
should be parsed as an event-value
with an unspecified (i.e. default) eventbase-element.
.begin" or
".end", then the value should be parsed as a
syncbase-value.
.marker(", then the value
should be parsed as a
media-marker-value.
@@Note that this approach essentially reserves the following tokens:
prev and wallclock for element IDs, and
begin, end and marker for event names.
Clock values have the following syntax:
Clock-val ::= ( Full-clock-val | Partial-clock-val | Timecount-val )
Full-clock-val ::= Hours ":" Minutes ":" Seconds ("." Fraction)?
Partial-clock-val ::= Minutes ":" Seconds ("." Fraction)?
Timecount-val ::= Timecount ("." Fraction)? (Metric)?
Metric ::= "h" | "min" | "s" | "ms"
Hours ::= DIGIT+; any positive number
Minutes ::= 2DIGIT; range from 00 to 59
Seconds ::= 2DIGIT; range from 00 to 59
Fraction ::= DIGIT+
Timecount ::= DIGIT+
2DIGIT ::= DIGIT DIGIT
DIGIT ::= [0-9]
For Timecount values, the default metric suffix is "s" (for seconds). No embedded white space is allowed in clock values, although leading and trailing white space characters will be ignored.
The following are examples of legal clock values:
02:30:03 50:00:10.25 = 50 hours, 10 seconds and 250 milliseconds
02:33 00:10.5 = 10.5 seconds = 10 seconds and 500 milliseconds
3.2h = 3.2 hours = 3 hours and 12
minutes 45min = 45 minutes 30s = 30 seconds 5ms = 5 milliseconds 12.467 = 12 seconds and 467 milliseconds
Fractional values are just (base 10) floating point definitions of seconds.
The number of digits allowed is unlimited (although actual precision may
vary among implementations).
For example:
00.5s = 500 milliseconds 00:00.005 = 5 milliseconds
An offset value has the following syntax:
offset-value ::= ( "+" | "-" )?( Clock-value )
An offset value allows an optional sign on a clock value, and is used to indicate a positive or negative offset. The offset is measured in local time on the parent time container.
The implicit syncbase for an offset value is dependent upon the time container:
<par> or an
<excl>, the offset is relative to the begin of the parent
<par> or <excl>.
<seq>, the offset is relative to the
active end of the previous child. If there is no previous child, the offset
is relative to the begin of the parent <seq>. See also
The seq time container.
Note, only compliant SMIL document players are required to support the SMIL 1.0 syncbase-value syntax. Language designers integrating SMIL Boston Timing and Synchronization into other languages should not support this syntax.
smil-1-syncbase-value ::= "id(" id-ref ")"
( "(" ( "begin" | "end" | clock-value) ")" )?
ID reference values are references to the value of an "id" attribute of another element in the document.
Id-value ::= IDREF
The IDREF is a legal XML identifier.
A syncbase value has the following syntax:
Syncbase-value ::= ( Syncbase-element "." Time-symbol
)
( S ("+"|"-")
S Clock-value )?
Syncbase-element ::= Id-value
Time-symbol ::= "begin" | "end"
A syncbase value starts with a Syncbase-element term defining the value of an "id" attribute of another element referred to as the syncbase element. The syncbase element must be another timed element contained in the host document. In addition, the syncbase element may not be a descendent of the current element. If the syncbase element specification refers to an illegal element, the syncbase-value description is ignored (although the entire time value list is not invalidated - only the particular syncbase value).
The syncbase element is qualified with one of the following time symbols:
The time symbol can be followed by an offset value. The offset value specifies an offset from the time (i.e. the begin or active end) specified by the syncbase and time symbol. The offset is measured in local time on the parent time container. If the clock value is omitted, it defaults to "0".
No embedded white space is allowed between a syncbase element and a time-symbol. White space will be ignored before and after a "+" or "-" for a clock value. Leading and trailing white space characters (i.e. before and after the entire syncbase value) will be ignored.
Examples:
begin="x.end-5s" : Begin
5 seconds before "x" ends
begin=" x.begin " : Begin when
"x" begins
begin="x.begin + 1m" : End 1 minute after
"x" begins
A sync-to-prev value has the following syntax:
SyncToPrev-value ::= ( "prev." Time-symbol )
(
S ("+"|"-")
S Clock-value )?
A sync-to-prev value is much like a syncbase value, except that the reserved token "prev" is used in place of the Syncbase-element term. The Time-symbol and optional Clock-value offset are as defined for syncbase values.
The previous element is the (timed) element that precedes this element within the parent time container (as reflected in the DOM). Note that the parent time container may not be the immediate parent of the current node, in some host documents.
If there is no previous element (i.e. if the current element is the first timed child of the parent time container), then the begin of the parent time container is used as the syncbase (note that the Time-symbol is ignored in this case). The Clock-value offset is nevertheless added to the parent time container begin time, to yield the resulting time value.
@@This requires more complete examples, or we need to include them above somewhere. We need good examples of how this is used.
Examples:
begin="prev.end-5s" :
Begin 5 seconds before the previous element ends
begin=" prev.begin " : Begin
when the previous element begins
begin="prev.begin + 1m" : End 1 minute after
the previous element begins
An event value has the following syntax:
Event-value ::= (
Eventbase-element "." )? Event-symbol
( S ("+"|"-")
S Clock-value )?
Eventbase-element ::= Id-value
An Event value starts with an Eventbase-element term that specifies the
event-base element. The event-base element is the element on which
the event is observed. Given DOM event bubbling, the event-base element may
be either the element that raised the event, or it may be an ancestor element
on which the bubbled event can be observed. Refer to DOM-Level2-Events
[DOM2Events] for details.
The "Id-value" is the value of an attribute declared to be of type ID (per
the XML definition) in the host language, for the event-base element. This
element must be another element contained in the host document.
If the Eventbase-element term is missing, the event-base element defaults
to the element on which the attribute is specified (the current element).
If this element has no associated layout (e.g. a time container in a SMIL
document), then some UI events may not be defined (e.g. mouse events). Note
that certain elements may specify a different default eventbase. E.g. the
SMIL Animation elements (animate, animateMotion,
etc.) specify that the default eventbase is the target element of
the animation. See also [[SMIL Animation]].
The event value must specify an Event-symbol. This term specifies the name of the event that is raised on the Event-base element. The host language designer must specify which types of events can be used. If an integrating language specifies no supported events, the event-base time value is effectively unsupported for that language.
The last term specifies an optional offset-value that is an offset from the time of the event. The offset is measured in local time on the parent time container. If this term is omitted, the offset is 0.
No embedded white space is allowed between an eventbase element and an event-symbol. White space will be ignored before and after a "+" or "-" for a clock value. Leading and trailing white space characters (i.e. before and after the entire eventbase value) will be ignored.
Note that it is not considered an error to specify an event that cannot be raised on the Event-base element (such as click for audio or other non-visual elements). Since the event will never be raised on the specified element, the event-base value is effectively ignored. Similarly, if the host language allows dynamically created events (as supported by DOM-Level2-Events [DOM2Events]), all possible Event-symbol names cannot be specified, and so unrecognized names may not be considered errors. Host language specifications must include a description of legal event names, and/or allow any name to be used.
The semantics of event-based timing are detailed in the section Unifying Scheduling and Interactive Timing.
Examples:
begin=" x.load " : Begin when "load" is observed
on "x"
begin="x.focus+3s" : Begin 3 seconds after an "focus"
event on "x"
Certain types of media can have associated marker values that associate a name with a particular point (i.e. a time) in the media. The media marker value provides a means of defining a begin or end time in terms of these marker values. Note that if the referenced id is not associated with a media element that supports markers, or if the specified marker name is not defined by the media element, the associated time may never be resolved.
Media-Marker-value ::= Id-value ".marker("
S
marker-symbol S ")" )
The marker symbol is a string that must conform to the definition of marker names for the media associated with the Id-value.
Wallclock-sync values have the following syntax. The values allowed are based upon several of the "profiles" described in [DATETIME], which is based upon [ISO8601]. Exactly the components shown here must be present, with exactly this punctuation. Note that the "T" appears literally in the string, to indicate the beginning of the time element, as specified in [ISO8601].
wallclock-val ::= "wallclock(" S (DateTime | WallTime) S ")"
DateTime ::= Date "T" WallTime
Date ::= Years "-" Months "-" Days
WallTime ::= (HHMM-Time | HHMMSS-Time)(TZD)?
HHMM-Time ::= Hours24 ":" Minutes
HHMMSS-Time ::= Hours24 ":" Minutes ":" Seconds ("." Fraction)?
Years ::= 4DIGIT;
Months ::= 2DIGIT; range from 01 to 12
Days ::= 2DIGIT; range from 01 to 31
Hours24 ::= 2DIGIT; range from 00 to 23
4DIGIT ::= DIGIT DIGIT DIGIT DIGIT
TZD ::= "Z" | (("+" | "-") Hours24 ":" Minutes )
Complete date plus hours and minutes: YYYY-MM-DDThh:mmTZD (e.g. 1997-07-16T19:20+01:00) Complete date plus hours, minutes and seconds: YYYY-MM-DDThh:mm:ssTZD (e.g. 1997-07-16T19:20:30+01:00) Complete date plus hours, minutes, seconds and a decimal fraction of a second YYYY-MM-DDThh:mm:ss.sTZD (e.g. 1997-07-16T19:20:30.45+01:00)
Note that the Minutes, Seconds, Fraction, 2DIGIT and DIGIT syntax is as defined for Clock-values. Note that white space is not allowed within the date and time specification.
There are three ways of handling time zone offsets:
No embedded white space is allowed in wallclock values, although leading and trailing white space characters will be ignored.
The presentation engine must be able to convert wallclock-values to a time
within the document. When the document begins, the current wallclock time
must be noted - this is the document wallclock begin. Wallclock
values are then converted to a document time by subtracting the document
wallclock begin, and then converting the time to the element's parent time
space as for any syncbase value, as though the syncbase were the document
body. Note that the resulting begin or end time may be before the begin,
or after end of the parent time container. This is not an error, but the
time container constraints
still apply. In any case, the semantics of the begin and
end attribute govern the interpretation of the wallclock value.
The following examples all specify a begin at midnight on January 1st 2000, UTC
begin="wallclock(2000-01-01Z)" begin="wallclock( 2000-01-01T00:00Z )" begin="wallclock( 2000-01-01T00:00:00Z )" begin="wallclock( 2000-01-01T00:00:00.0Z )" begin="wallclock( 2000-01-01T00:00:00.0Z )" begin="wallclock( 2000-01-01T00:00:00.0-00:00 )"
The following example specifies a begin at 3:30 in the afternoon on July 28th 1990, in the Pacific US time zone:
begin="wallclock( 1990-07-28T15:30-08:00 )"
The following example specifies a begin at 8 in the morning wherever the document is presented:
begin="wallclock( 08:00 )"
New element controls for element time behavior are under discussion. Note that an Accessibility requirement for control of the playback speed is related to (but may end up with different syntax different from) the speed control. In general, these time manipulations are suited to animation and non-linear or discrete media, rather than linear continuous media. Not all continuous media types will support time manipulations, e.g. streaming MPEG 1 video playing backwards. A fallback mechanism is described for these cases.
Three new attributes add support for timing manipulations to SMIL Timing, including control over the speed of an element, and support for acceleration and deceleration. The impact on overall timing and synchronization is described. A definition is provided for reasonable fallback mechanisms for media players that cannot support the time manipulations.
A common general application of timing supports animation. The recent integration of SMIL timing with SVG is a good example of the interest in this area. Animation in the more general sense includes the time-based manipulation of basic transforms, applied to a presentation. Some of the effects supported include motion, scaling, rotation, color manipulation, as well as a host of presentation manipulations with a style framework like CSS.
Animation is often used to model basic mechanics. Many animation use-cases are difficult or nearly impossible to describe without a simple means to control pacing and to apply simple effects that emulate common mechanical phenomena. While it is possible to build these mechanisms into the animation behaviors themselves, this requires that every animation duplicate this support. This makes the framework more difficult to extend and customize. In addition, this model allows any animation behavior to introduce individual syntax and semantics for these mechanisms. This makes the authoring model much harder to learn, and complicates the job of any authoring tool designer as well. Finally, this model precludes the use of these mechanisms on structured animations (e.g. a time container with a series of synchronized animation behaviors).
A much simpler model for providing the necessary support centralizes the needed functionality in the timing framework. This allows all timed elements to support this functionality, and provides a consistent model for authors and tools designers. The most direct means to generalize pacing and related functionality is to transform the pacing of time for a given element. This is an extension of the transform that is implicitly performed to translate from the general document or presentation time space to the adjusted time space for the element (accounting for the begin time of the element, repeat functionality, etc.). Thus, to control the pacing of a motion animation, a transform is applied that adjusts the pacing of local time for the motion element. If time is scaled to advance faster than normal presentation time, the motion will appear to run faster. Similarly, if the pacing of time is dynamically adjusted, acceleration and deceleration effects are easily obtained. This model is detailed in the sections below.
Three basic time manipulations are proposed:
speed
accelerate and
decelerate
autoReverse
This support is often represented to authors as "Play Forwards, then
Backwards". Because so many common use-cases apply repeat to the modified
local time (as in the examples above), this function is modeled as modifying
the simple duration. As such, autoReverse effectively doubles
the simple duration.
When the three features are combined, there is an inherent ordering that can be applied. The accelerate and decelerate features are applied locally on the simple duration, and have no side effects upon the active duration of the element. The autoReverse feature is applied to the simple duration, and doubles it. Thus, autoReverse wraps the effect of accelerate and decelerate. Speed has the broadest effect, scaling the progress of local time for the element. Taken from the perspective of a conversion from the document time-space to the local time-space, speed is applied earliest, autoReverse later and and then accelerate and decelerate are applied latest. See also Details of the time manipulations.
The following motion animation will move the target twice as fast as normal:
<animateMotion dur="10s" repeatCount="2" speed="2.0" path= ... />
The target will move over the path in 5 seconds, and then repeat this motion. The active duration is thus 10 seconds.
The following rotation (a theoretical extension to the animation platform) will produce a simple pendulum swing on the target (assume that it is a pendulum shape with the transform origin at the top):
<animateRotate from="20deg" to="-20deg" dur="1s" repeatCount="indefinite"
accelerate=".5" decelerate=".5" autoReverse="true" ... />
The pendulum swings through an arc in one second, and then back again in
a second. It repeats indefinitely. The acceleration and deceleration are
specified as a proportion of the simple duration (before autoReverse). As
specified, the effect is to accelerate all the way through the downswing,
and then decelerate all through the upswing. This produces a very realistic
looking animation of real-world pendulum motion. The rotate
element itself can be very simple, for example interpolating the rotation
value in a transform matrix.
The speed attribute is supported on all timed elements. The
argument value expresses a multiple of normal play speed that will be applied
to the element and all time descendents. Thus 1.0 is normal speed, and
speed="1" is a no-op, and speed="-1" means play
backwards.
The speed attribute controls the local playback speed of an element, to speed up or slow down the effective rate of play. Note that the speed does not specify an absolute play speed, but rather is relative to the playback speed of the parent time container. Thus if a <par> and one of its children both specify a speed of 50%, the child will play at 25% of normal playback speed .
Legal values are signed floating point values. A value of 0 is not allowed.
The default is "1.0" (no modification of speed).
The details of the speed modification are described in Details of the time manipulations.
These attributes define a simple acceleration and deceleration of element time, within the simple duration. This is useful for animation, motion paths, etc. The values are expressed as a proportion of the simple duration (i.e. between 0 and 1), and are defined such that the simple duration is not affected (although the normal play speed is increased to compensate for the periods of acceleration and deceleration). Note that these attributes apply to the simple duration; if these attributes are combined with repeating behavior, the acceleration and/or deceleration occurs within each repeat iteration.
The sum of accelerate and decelerate must not exceed
1. If it does, the deceleration value will be reduced to make the sum legal
(i.e. the value of accelerate will be clamped to 1, and then
the value of decelerate will be clamped to
1-accelerate ).
The details of the accelerate and decelerate modifications are described in Details of the time manipulations.
In this example, a motion path will accelerate up from a standstill over
the first 2 seconds, run at a faster than normal rate for 4 seconds, and
then decelerate smoothly to a stop during the last 2 seconds. This
makes an animation look more realistic. The animateMotion element
is defined in the Animation section of SMIL Boston.
<img ...>
<animateMotion dur="8s" accelerate=".25" decelerate=".25" .../>
</img>
In this example, the image will "fly in" from off-screen left , and then
decelerate quickly during the last second to "ease in" to place. This assumes
a layout model that supports positioning (a similar effect could be achieved
by animation the position of a region in SMIL layout). The
animate element is defined in the Animation section of SMIL
Boston.
<img ...>
<animate attributeName="left" dur="4s" decelerate=".25"
from="-1000" to="0" additive="sum" />
</img>
This defines "play forwards then backwards" functionality. The use of autoReverse effectively doubles the simple duration. When combined with repeating behavior, each repeat iteration will play once forwards, and once backwards. This is useful for animation, especially for mechanical and pendulum motion.
Argument values are Booleans.
The default value is false (i.e. play normally).
The details of the autoReverse modification are described in Details of the time manipulations.
In this example, a motion path will animate normally for 5 seconds moving
the element 20 pixels to the right, and then run backwards for 5 seconds
(from 20 pixels to the right back to the original position), then forwards
again and then backwards again, leaving the element at its original location.
The active duration of the animation is 20 seconds. The
animateMotion element is defined in the Animation section of
SMIL Boston.
<img ...>
<animateMotion by="20, 0" dur="5s" autoReverse="true" repeatCount="2"/>
</img>
SMIL 1.0 introduced the repeat attribute, which is used to repeat a media
element or an entire time container. SMIL Boston introduces two new controls
for repeat functionality that supercede the SMIL 1.0 repeat
attribute. The new attributes, repeatCount and
repeatDur, provide a semantic that more closely matches typical
use-cases, and the new attributes provide more control over the duration
of the repeating behavior. The SMIL 1.0 repeat attribute is deprecated
in SMIL Boston (it must be supported in SMIL document players for backwards
compatibility).
Repeating an element causes the simple duration to be "played" several times
in sequence. This will effectively copy or loop the contents of
the element media (or an entire timeline in the case of a time container).
The author can specify either how many times to repeat, using
repeatCount, or how long to repeat, using
repeatDur. Each repeat iteration is one instance of
"playing" the simple duration.
If the simple duration is indefinite, the element cannot repeat. In this
case, any repeatCount attribute is ignored, although a
repeatDur attribute value can still constrain the active duration.
See also Computing the Active
Duration.
At most one of repeatCount or repeatDur should
be specified. If both are specified (and the simple duration is not indefinite),
the active duration is defined as the minimum of the specified
repeatDur, and the simple duration multiplied by
repeatCount. For the purposes of this comparison, a defined
value is considered to be "less than" a value of "indefinite".
If the simple duration is indefinite, any repeatCount attribute
will be ignored. Any repeatDur attribute value (other than
"indefinite") will be used to constrain the indefinite simple duration. See
also the examples below describing repeatDur and an indefinite
simple duration.
If the simple duration is 0, any repeatCount attribute will
be ignored. Any repeatDur attribute value will be used to define
the active duration by showing the state of the element for the specified
duration (this may be constrained by an end value - see
Controlling active duration). See also the
examples below describing repeatDur and a simple duration of
0).
@@ If simple duration is 0 and repeatCount is "indefinite" is the active duration 0 or indefinite?
If an element specifying audio media has a simple duration of 0 (e,g, because
of clipBegin and clipEnd values), nothing should
played even if the repeatDur specifies an active duration. The time model
behaves according to the description, but no audio should be played.
These rules are included in the section Computing the Active Duration.
Need to create normative examples that demonstrate the new controls, and the interaction with implicit and explicit simple durations. Examples must also demonstrate the interaction of repeating behavior and time container constraints.
@@ Need to add example of repeatCount < 1 and/or repeatDur < simple duration
In the following example, the 2.5 second simple duration will be repeated twice; the active duration will be 5 seconds.
<audio src="background.au" dur="2.5s" repeatCount="2" />
In the following example, the 3 second (implicit) simple duration will be repeated two full times and then the first half is repeated once more; the active duration will be 7.5 seconds.
<audio src="3second_sound.au" repeatCount="2.5" />
In the following example, the audio will repeat for a total of 7 seconds. It will play fully two times, followed by a fractional part of 2 seconds. This is equivalent to a repeatCount of 2.8.
<audio src="music.mp3" dur="2.5s" repeatDur="7s" />
Note that if the simple duration is zero (0) or indefinite, repeat behavior
is not defined (but repeatDur still contributes to the active
duration). In the following example the simple duration is 0 and indefinite
respectively, and so the repeatCount is effectively ignored.
Nevertheless, this is not considered an error. The active is equal to the
simple duration: for the first element, the active duration is 0, and for
the second element, the active duration is indefinite.
<img src="foo.jpg" repeatCount="2" /> <img src="bar.png" dur="indefinite" repeatCount="2" />
In the following example, the simple duration is 0, and so repeat behavior
is not meaningful. However, the repeatDur determines the active
duration. The effect is that the text is shown for 10 seconds.
<text src="intro.html" repeatDur="10s" />
In the following example, if the audio media is longer than the 5 second
repeatDur, then the active duration will effectively cut short
the simple duration.
<audio src="8second_sound.au" repeatDur="5s" />
The repeatCount and repeatDur attributes can also
be used to repeat an entire timeline (i.e. a time container simple duration),
as in the following example. The sequence has an implicit simple duration
of 13 seconds. It will begin to play after 5 seconds, and then will
repeat the sequence of three images 3 times. The active duration is thus
39 seconds long.
<seq begin="5s" repeatCount="3" > <img src="img1.jpg" dur="5s" /> <img src="img2.jpg" dur="4s" /> <img src="img3.jpg" dur="4s" /> </seq>
The SMIL 1.0 repeat attribute behaves in a manner similar to repeatCount, but it defines the functionality in terms of a sequence that contains the specified number of copies of the element without the repeat attribute. This definition has caused some confusion among authors and implementers. See also the SMIL 1.0 specification [SMIL10].
In particular, there has been confusion concerning the behavior of the SMIL
1.0 end attribute when used in conjunction with the
repeat attribute. SMIL Boston complies with the common practice
of having the end attribute define the element's simple duration
when the deprecated repeat attribute is used. Only SMIL document
players must support this semantic for the end attribute. Only
a single SMIL 1.0 "end" value (i.e. an
offset-value or a
smil-1.0-syncbase-value,
but none of the new SMIL Boston timing) is permitted when used with the
deprecated repeat attribute. If repeat is used
with repeatCount or repeatDur on an element, or
if repeat is used with an illegal end value, the
repeat value is ignored.
<seq> element with the stated number
of copies of the element without the "repeat" attribute as children. All
other attributes of the element, including any begin delay, are included
in the copies.
Note that elements that use the SMIL 1 repeat attribute with
a value of "indefinite" are defined to end immediately after they begin.
I.e. the active duration is effectively defined to be 0. This semantic is
specific to the SMIL 1 repeat attribute, and does not apply
to the new repeatCount and repeatDur attributes.
SMIL Boston provides an additional control over the active duration. The
end attribute allows the author to constrain the active duration
of the animation by specifying an end value using a simple offset, a time
base, an event-base or DOM methods calls. The end attribute
generally constrains the active duration that is otherwise defined
by dur and any repeat behavior, although it will extend an
implicit simple duration (see examples below). The rules for combining
the attributes to compute the active duration are presented in the next section,
Computing the active duration.
The normative syntax rules for each attribute value variant are described in the section Timing Attribute Values; a syntax summary is provided here as an aid to the reader.
endElement() method call.
If end specifies an event-value or syncbase-value that is not
resolved, the value of end is considered to be "indefinite"
until resolved.
The end value can specify a list of times. This can be used to specify multiple "ways" or "rules" to end an element, e.g. if any one of several events is raised. A list of times can also define multiple end times that can correspond to multiple begin times, allowing the element to play more than once (this behavior can be controlled - see also Restarting elements).
In general, the earliest time in the list determines the end value used in Computing the Active Duration. In the case where an element can begin multiple times, the end value used is the earliest end time after the current begin time. There are additional constraints upon the evaluation of the begin and end time lists, detailed in Evaluation of begin and end time lists.
The end value generally constrains all other values, and does not extend
the active duration. However it will extend an implicit simple
duration. In the following example, the dur attribute is
not specified, and so the simple duration is defined to be the implicit media
duration. In this case (and this case only) the value of end
will extend the active duration if it specifies a duration greater than the
implicit (media) duration. For the difference between the implicit
simple duration and the active duration, the ending state of the media (e.g.
the last frame of video) will be shown. This only applies to visual media
- aural media will simply stop playing, or will not play at all if the implicit
simple duration is 0 (e,g, because of clipBegin and
clipEnd values).
In the following example, the video will be shown for 8 seconds, and then the last frame will be shown for 2 seconds.
<video end="10s" src="8-SecondVideo.mpg" .../>
If the end value becomes resolved while the element is still
active, and the resolved time is in the past, the element should end the
active duration immediately. Time dependents defined relative to the end
of this element should be resolved using the computed active end (which may
be in the past), and not the observed active end. These cases arise from
the use of negative offsets in the sync-base and event-base forms, and authors
should be aware of the complexities this can introduce. See also
Handling negative offsets.
In the following example, the active duration will end at the earlier of 10 seconds, or the end of the "foo" element. This is particularly useful if "foo" is defined to begin or end relative to an event.
<audio src="foo.au" dur="2s" repeatDur="10s"
end="foo.end" .../>
In the following example, the active duration will end at 10 seconds, and will cut short the simple duration defined to be 20 seconds. The effect is that only the first half of the element is actually played. For a simple media element, the author could just specify this using the dur attribute. However in other cases, it is sometimes important to specify the simple duration independent of the active duration.
<par> <audio src="music.au" dur="20s" end="10s" ... /> </par>
In the following example, the element begins when the user clicks on the "gobtn" element. The active duration will end 30 seconds after the parent time container begins. Note that if the user has not clicked on the target element before 30 seconds elapse, the element will never begin.
<par> <audio src="music.au" begin="gobtn.click" repeatDur="indefinite" end="30s" ... /> </par>
The defaults for the event syntax make it easy to define simple interactive behavior. The following example stops the image when the user clicks on the element.
<image src="image.jpg" end="click" />
Using end with an event value enables authors to end an element
based on either an interactive event or a maximum active duration. This is
sometimes known as lazy interaction.
In this example, a presentation describes factory processes. Each step is a video, and set to repeat 3 times to make the point clear. Each element can also be ended by clicking on the video, or on some element "next" that indicates to the user that the next step should be shown.
<seq> <video dur="5s" repeatCount="3" end="click; next.click" .../> <video dur="5s" repeatCount="3" end="click; next.click" .../> <video dur="5s" repeatCount="3" end="click; next.click" .../> <video dur="5s" repeatCount="3" end="click; next.click" .../> <video dur="5s" repeatCount="3" end="click; next.click" .../> </seq>
In this case, the active end of each element is defined to be the earlier of 15 (5s dur * 3 repeats) seconds after it begins, or a click on "next". This lets the viewer sit back and watch, or advance the presentation at a faster pace.
This section still needs work - and will change in the next day or two.
The table in Figure 3 defines a set of "forms" for the simple duration. These forms are used in the table in Figure 4 to delineate the possible combinations of attributes that can contribute to the active duration.
dur |
Implicit media duration | Simple Duration | Form |
| number | * | dur value |
explicit finite |
| "indefinite" | * | indefinite | "indefinite" |
| unspecified | 0 | media dur | implicit 0 |
| unspecified | number | media dur | implicit finite |
| unspecified | continuous indefinite | indefinite | implicit indefinite |
| unspecified | unresolved | indefinite | unresolved |
Figure 3 - Describing the simple duration
@@There are two forms of table 4 presented. We are trying to decide which presents the information more effectively. You be the judge which makes more sense, which is clearer, and which we should include. Both use essentially the same terminology, and present the same semantics (i.e. there should be no discrepancy in the semantics described, but rather only differences in how the information is presented).
The table in Figure 4 shows the semantics of all possible combinations of
simple duration, repeatCount and repeatDur, and
end. The following conventions are used in the table:
repeatCount and repeatDur attributes are specified
as either:
end attribute column specifies the end value obtained by
evaluating the the attribute value according to the rules described in
Controlling active duration and
Evaluation of begin and end
time lists. Note that a list of values yields a single end value at any
given point of evaluation.
Note in particular that where a value specifies "unresolved", that the table will be reevaluated (generally using a different row) if and when the associated value becomes resolved. For example if the element specifies:
<audio src="5-second.au" end="foo.click" />
The active duration is initially defined as equal to the (implicit finite) simple duration. If the user clicks on "foo" before 5 seconds, the end value becomes resolved and the active duration table is re-evaluated to be MIN( d, end-B) which causes the element to end at the time of the click.
Some of the rules and results that are implicit in the table, and that should be noted in particular are:
end and dur are specified but neither of
repeatCount or repeatDur are specified, then the
active duration AD is defined as the minimum
of the simple duration and the duration defined by end.end is specified (i.e. none of dur,
repeatCount or repeatDur are specified), then the
active duration AD is defined as the duration
defined by end (in this case end overrides any
implicit simple duration).end and either (or both) of repeatCount
or repeatDur are specified, the active duration
AD is defined by the minimum duration defined
by the respective attributes.AD divided by the simple duration
d (this may yield partial repeat iterations,
just as repeatCount can specify).
Note that while the active duration is computed according to the rules in the table, the parent time container places constraints upon the active duration of all children. These constraints may cut short the active duration of any child, and so override the definition described here. For more information, see the section Time Container constraints on child durations.
The following symbols are used in the table as a shorthand:
@@This is a form of the table that has more rows, but may be clearer in delineating the different cases. It uses the term "unresolved indefinite" for end values, which is semantically equivalent to "unresolved" in the second table.
@@Note that in both table the handling of explicit 0 is a bit messy. This is only needed if we want to say that simple Dur of 0 and repeatCount of "indefinite" yields a 0 active duration, rather than an indefinite AD. The tables would simplify if we went with the latter.
Where the Active duration has a "+" suffix, the value may be reevaluated at some point. The footnotes within the row indicate when the value will be reevaluated. Note that when a value is re-evaluated, a different row in the table may apply.
| Simple duration(d) | repeatCount |
repeatDur |
end |
Active Duration |
| implicit 0 or explicit 0 |
(ignored) | unspecified | unspecified | 0 |
| implicit 0 or explicit 0 |
(ignored) | "indefinite" | unspecified | indefinite |
| explicit finite or implicit finite | unspecified | unspecified | unspecified | d |
| explicit finite or implicit finite | unspecified | unspecified | unresolved indefinite1 or "indefinite"2 | d+ |
| "indefinite" or implicit indefinite | (ignored) | "indefinite" or unspecified | unspecified | indefinite |
| "indefinite", implicit 0, or implicit indefinite | (ignored) | "indefinite" or unspecified | unresolved indefinite1 or "indefinite"2 | indefinite+ |
| unresolved3 | number or unspecified | "indefinite" or unspecified | unresolved indefinite1 or "indefinite"2 | indefinite+ |
| unresolved3 | number | "indefinite" | unspecified | indefinite+ |
| unresolved3 | (ignored) | unspecified | unspecified | indefinite+ |
| explicit finite or implicit finite | number | "indefinite" or unspecified | unspecified | repeatCount*d |
| explicit finite or implicit finite | number | "indefinite" or unspecified | unresolved indefinite1 or "indefinite"2 | repeatCount*d+ |
| (ignored) | "indefinite" or unspecified | number | unspecified | repeatDur |
| (ignored) | "indefinite" or unspecified | number | unresolved indefinite1 or "indefinite"2 | repeatDur+ |
| "indefinite", implicit 0, or implicit indefinite | (ignored) | number | unspecified | repeatDur |
| "indefinite", implicit 0, or implicit indefinite | (ignored) | number | unresolved indefinite1 or "indefinite"2 | repeatDur+ |
| unresolved3 | number | number | unspecified, unresolved indefinite1, or "indefinite"2 | repeatDur+ |
| explicit finite | unspecified | unspecified | number | MIN(d, end-B) |
| explicit finite | unspecified | "indefinite" | number | end-B |
| "indefinite", implicit 0, or implicit indefinite | (ignored) | "indefinite" or unspecified | number | end-B |
| unresolved3 | number | "indefinite" or unspecified | number | end-B+ |
| (ignored) | "indefinite" | "indefinite" or unspecified | number | end-B |
| implicit finite or unresolved | unspecified | "indefinite" or unspecified | number | end-B |
| explicit finite or implicit finite | "indefinite" | "indefinite" or unspecified | unspecified | indefinite |
| (ignored) | unspecified | "indefinite" | unresolved indefinite1 or "indefinite"2 | indefinite+ |
| (ignored) | "indefinite" or unspecified | "indefinite" | unspecified | indefinite |
| (ignored) | "indefinite" | "indefinite" or unspecified | unresolved indefinite1 or "indefinite"2 | indefinite+ |
| explicit finite or implicit finite | number | number | unspecified | MIN(repeatDur,
repeatCount*d) |
| explicit finite or implicit finite | number | number | unresolved indefinite1 or "indefinite"2 | MIN(repeatDur,
repeatCount*d)+ |
| explicit finite or implicit finite | number | number | number | MIN(end-B, repeatDur,
repeatCount*d) |
| (ignored) | "indefinite" or unspecified | number | number | MIN(end-B, repeatDur) |
| explicit finite or implicit finite | number | "indefinite" or unspecified | number | MIN(end-B,
repeatCount*d) |
| "indefinite", implicit 0, or implicit indefinite | (ignored) | number | number | MIN(end-B, repeatDur) |
| unresolved3 | number | number | number | MIN(end-B, repeatDur)+ |
Figure. 4a: Computing the active duration for different combinations
of the simple duration, repeatDur and repeatCount,
and end.
1 reevaluate if/when end becomes resolved by event
2 reevaluate if/when end becomes resolved by DOM
3 reevaluate when simple duration is resolved
@@This is a form of the table that has fewer rows, and does not call out the values that may be re-evaluated.
Note that any row that includes an "unresolved" value may be re-evaluated at some point (i.e. if the value becomes resolved). Note that when a value is re-evaluated, a different row in the table may apply.
| Simple duration d |
repeatCount |
repeatDur |
end |
Active Duration |
| expl. finite | unspecified | unspecified | unspecified, "indefinite" or unresolved | d |
| implicit 0, or implicit finite |
unspecified | unspecified | unspecified | d |
| "indefinite", impl. indefinite or unresolved |
(ignored) | unspecified or "indefinite" | unspecified | indefinite |
| implicit 0 or explicit 0 |
"indefinite" | unspecified | unspecified | 0 |
| "indefinite", implicit finite, impl. indefinite or unresolved |
unspecified or "indefinite" | unspecified or "indefinite" | "indefinite" or unresolved | indefinite |
| expl. finite, implicit 0, or implicit finite |
expl. finite | unspecified or "indefinite" | unspecified, "indefinite" or unresolved | repeatCount*d |
| expl. finite or implicit finite |
unspecified or "indefinite" | expl. finite | unspecified, "indefinite" or unresolved | repeatDur |
| implicit 0, "indefinite", impl. indefinite or unresolved |
(ignored) | expl. finite | unspecified, "indefinite" or unresolved | repeatDur |
| expl. finite | unspecified | unspecified | expl. finite | MIN( d, end-B
) |
| expl. finite | "indefinite" | unspecified or "indefinite" | expl. finite | end-B |
| expl. finite | unspecified or "indefinite" | "indefinite" | expl. finite | end-B |
| implicit finite | unspecified or "indefinite" | unspecified or "indefinite" | expl. finite | end-B |
| implicit 0, "indefinite", impl. indefinite or unresolved |
(ignored) | unspecified or "indefinite" | expl. finite | end-B |
| (anything except a 0 value) | "indefinite" | unspecified or "indefinite" | unspecified, "indefinite" or unresolved | indefinite |
| (anything) | unspecified or "indefinite" | "indefinite" | unspecified, "indefinite" or unresolved | indefinite |
| expl. finite or implicit finite |
expl. finite | expl. finite | unspecified, "indefinite" or unresolved | MIN( repeatCount*d,
repeatDur ) |
| expl. finite or implicit finite |
expl. finite | expl. finite | expl. finite | MIN( repeatCount*d,
repeatDur,
( end-B )) |
| * | unspecified or "indefinite" | expl. finite | expl. finite | MIN( repeatDur,
( end-B )) |
| implicit 0, "indefinite", impl. indefinite or unresolved |
(ignored) | expl. finite | expl. finite | MIN( repeatDur,
( end-B )) |
| expl. finite or implicit finite |
expl. finite | unspecified or "indefinite" | expl. finite | MIN( repeatCount*d,
( end-B )) |
Figure. 4b: Computing the active duration for different combinations
of the simple duration, repeatDur and repeatCount,
and end.
It is possible to combine scheduled and interactive timing, e.g.:
<par dur="30s"> <img id="mutebutton" src="mute.jpg"/> <text src="description.html" /> <audio src="audio.au" end="mutebutton.click"/> </par>
The image and the text appear for the specified duration of the
<par> (30 seconds). The audio will stop early if the image is
clicked before the active end of the audio (which in this case is the duration
of the actual audio media "audio.au").
It is possible to declare both a scheduled duration, as well as an event-based active end. This facilitates what are sometimes called "lazy interaction" use-cases, such as a slideshow that will advance on its own, or in response to user clicks:
<seq> <img src="slide1.jpg" dur="10s" end="click" /> <img src="slide2.jpg" dur="10s" end="click" /> <img src="slide3.jpg" dur="10s" end="click" /> <!-- etc., etc. --> </seq>
In this case, the active end of each element is defined to be the earlier of the specified duration, or a click on the element. This lets the viewer sit back and watch, or advance the slides at a faster pace.
By default when an element's active duration ends, it is no longer presented (or its effect is removed from the presentation, depending upon the type of element). Freezing an element extends it, using the last state presented in the active duration. This can be used to fill gaps in a presentation, or to extend an element as context in the presentation (e.g. with additive animation - see [SMIL-ANIMATION]).
The fill attribute allows an author to specify that an element
should be extended beyond the active duration by freezing the final
state of the element. For discrete media, the media is simply displayed as
it would be during the active duration. For continuous media, the "frame"
that corresponds to the end of the active duration is shown. For algorithmic
media like animation, the value defined for the end of the active duration
should be used. The syntax of the fill attribute is the same as in
SMIL 1.0, with two extensions:
This attribute only has an effect on visual media elements. Non-visual media elements (audio) should ignore this.
Note that <a> and <area> elements are
still sensitive to user activation (e.g. clicks) when frozen. See also the
SMIL 1.0 specification [SMIL10].
The default value of the fill attribute depends on the element
type, and whether the element specifies any of the attributes that define
the simple or active duration.
<par>, <seq> and
<excl>), the default value is "remove".
dur,
end, repeatCount or repeatDur are
specified on the element, then the default value of fill is
"freeze".
An element with fill="freeze" is extended according to the parent
time container:
<par>, the element is frozen to extend to the end
of the simple duration of the <par>. In this case,
fill="freeze" is equivalent to fill="hold".
<seq>, the element is frozen to extend to the begin
of the next element in the <seq>. This will fill any gap
in the presentation (although it may have no effect if the next element begins
immediately).
<excl>, the element is frozen to extend to the begin
of the next element to be activated in the <excl>. This
will fill any gap in the presentation (although it may have no effect if
the next element interrupts the current element). Note that if an element
is paused, the active duration has not ended, and so the fill
attribute does not (yet) apply. See also the section
The excl time container.
The fill attribute can be used to maintain the value of an media
element after the active duration of the element ends:
<par endSync="last"> <video src="intro.mpg" begin= "5s" dur="30s" fill="freeze" /> <audio src="intro.au" begin= "2s" dur="40s"/> </par>
The video element ends 35 seconds after the parent time container began, but the video frame at 30 seconds into the media remains displayed until the audio element ends. The attribute "freezes" the last value of the element for the remainder of the time container's simple duration.
This functionality is also useful to keep prior elements on the screen while
the next item of a <seq> time container prepares to display
as in this example:
<seq> <video id="v1" fill="freeze" src.../> <video id="v2" begin="2s" src.../> </seq>
The first video is displayed and then the last frame is frozen for 2 seconds, until the next element begins. Note that if it takes additional time to download or buffer video "v2" for playback, the first video "v1" will remain frozen until video "v2" actually begins.
@@Need a good example of freeze on a time container, showing both how it extends any frozen children, as well as how it cuts off and freezes any children that were active at the end.
When an element is defined to begin at a simple offset (e.g.
begin="5s" ), there is an unequivocal time when the element
begins. However, if an element is defined to begin relative to an event (e.g.
begin="foo.click" ), the event can happen at any time, and moreover
can happen more than once (e.g. if the user clicks on "foo" several
times). In some cases, it is desirable to restart an element if
a second begin event is received. In other cases, an author may want to preclude
this behavior.
In SMIL Boston, an element can have a list of begin values. In some cases, the intent is to begin at the earliest of the specified times (e.g. when the user clicks on any one of several images). In other cases, the intent is that the element restart when any of the begin times is encountered.
In addition, if an element is defined to begin relative to when another element
begins (using the syncbase- value syntax), the syncbase element can restart.
The restart attribute is used to control the restart behavior
of an element.
restart
= "always | whenNotActive |
never"
The default value for the restart attribute is "always". This may not be a sensible default in all documents. In particular SMIL Boston documents with streaming media may want restart="never" set on all of the elements. In order to not require restart="never" be added to every media element in the document, the WG is considering ways to override the default and set a new default for the document.
Note that there are several ways that an element may be restarted. The behavior
(i.e. to restart or not) in all cases is controlled by the
restart attribute. The different restart cases are:
begin specified as an event-value can be restarted
when the named event fires multiple times.
begin specified as a syncbase value, where the
syncbase element can restart. When an element restarts, other elements defined
to begin relative to the begin or active end of the restarting element may
also restart (subject to the value of restart on these elements).
When an element restarts, the primary semantic is that it behaves as though this were the first time the element had begun, independent of any earlier behavior. Any effect of an element playing earlier is no longer applied, and only the current begin "instance" of the element is reflected in the presentation.
The synchronization relationship between an element and its parent time container is re-established when the element restarts. A new synchronization relationship may be defined. See also Controlling runtime synchronization behavior.
As with any begin time, if an element is scheduled to restart after the end of the parent time container simple duration, the element will not restart.
Note that if the parent time container (or any ascendant time container)
repeats or restarts, any state associated with restart="never"
will be reset, and the element can begin again normally. See also
Resetting element state.
The restart setting for an animation is evaluated when the syncbase element
restarts, when the eventbase event happens, or when the DOM method call (e.g.
beginElement()) happens. For example:
<img id="g