This section is informative
The SMIL 2.1 specification leaves the basic syntax and semantics of the SMIL 2.0 timing model unchanged [SMIL20-timing]. The only changes for SMIL 2.1 are that SMIL 2.0's ExclTimeContainers module is deprecated and replaced with two new modules: BasicExclTimeContainers and BasicPriorityClassContainers, an errata note has been integrated into the specification that clarifies the default event base for animation elements, and a fix for a text error in the fourth bullet of the begin and end values was integrated into the text. The repartitioning of the ExclTimeContainers module is done to reduce the implementation burden of the excl element on low-powered devices or in implementations in which the full functionality of the priority class mechanism of SMIL 2.0 is not required. The clarification of the event base for animation elements makes integration with SMIL timing and SMIL animation clearer for implementers. The change related to the begin and end values allows an unresolved name to be ignored.
As a result of this change, SMIL 2.1 Timing and Synchronization support is broken down into 16 modules instead of the 15 modules used in SMIL 2.0. These modules are described in Appendix A: SMIL Timing and Synchronization modules.
This section is informative
SMIL 1.0 solved fundamental media synchronization problems and defined a powerful way of choreographing multimedia content. SMIL 2.1 extends the timing and synchronization support, adding capabilities to the timing model and associated syntax. Some SMIL 1.0 syntax has been changed or deprecated. This section of the document specifies the Timing and Synchronization module.
There are two intended audiences for this module: implementers of SMIL 2.1 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.
SMIL 2.1 Timing and Synchronization support is broken down into 16 modules, allowing broad flexibility for language designers integrating this functionality. These modules are described in Appendix A: SMIL Timing and Synchronization modules.
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 given time, or 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.
An element becomes active when it begins its active duration, and becomes inactive when it ends its active duration. Within the active duration, the element is active, and outside the active duration, the element is inactive.
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. The time graph is a dynamic structure, changing to reflect the effect of user events, media delivery, and DOM control of the presentation. At any given instant, the time graph models the document at that instant, and the semantics described in this module. However, as user events or other factors cause changes to elements, the semantic rules are re-evaluated to yield an updated time graph.
When a begin or end value refers to an event, or to the begin or active end of another element, it may not be possible to calculate the time value. For example, if an element is defined to begin on some event, the begin time will not be known until the event happens. Begin and end values like this are described as unresolved. When such a time becomes known (i.e. when it can be calculated as a presentation time), the time is said to be resolved. A resolved time is said to be definite if it is not the value "indefinite". See also the discussion of Unifying scheduled and interactive timing.
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.
This section is informative
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.
This section defines the set of timing attributes that are common to all of the SMIL synchronization elements.
Unless otherwise specified below, if there is any error in the argument value syntax for an attribute, the attribute will be ignored (as though it were not specified).
This section is informative
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 begin attribute syntax is described below. The normative syntax rules for each attribute value variant are described in Timing attribute value grammars; an attribute value syntax summary is provided here as an aid to the reader.
This section is normative
This section is normative
id(Id-value)(begin) is equivalent to
Id-value.begin id(Id-value)(end) is equivalent to
Id-value.endid(Id-value)(Clock-value) is equivalent
to Id-value.begin+ Clock-valueThis section is informative
Children of a par begin by default
when the par begins (equivalent to
begin="0s"). Children of a seq begin by default when the previous child
ends its active duration (equivalent to begin="0s"); the first
child begins by default when the parent seq begins. 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 the restart attribute).
In general, the earliest time in the list determines the begin time of the element. There are additional constraints upon the evaluation of the begin time list, detailed in Evaluation of begin and end time lists.
Note that while it is legal to include "indefinite" in a list of values for begin, "indefinite" is only really useful as a single value. Combining it with other values does not impact begin timing, as DOM begin methods can be called with or without specifying "indefinite" for begin.
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 known as timespace conversion, and is detailed in the section Converting between local and global times.
This section is informative
The use of negative offsets to define begin times merely defines the synchronization relationship of the element. It does not in any way override the time container constraints upon the element, and it cannot override the constraints of presentation time.
This section is normative
The computed begin time defines the scheduled synchronization relationship of the element, even if it is not possible to begin the element at the computed time. The time model uses the computed begin time, and not the observed time of the element begin.
This section is informative
If an element has a begin time that resolves to a time before the parent time container begins, the parent time container constraint still applies. For example:
<par> <video id="vid" begin="-5s" dur="10s" src="movie.mpg" /> <audio begin="vid.begin+2s" dur="8s" src="sound.au" /> </par>
The video element cannot begin before the par begins. The begin is simply defined to occur "in the past" when the par begins. The viewer will observe that the video begins 5 seconds into the media, and ends after 5 seconds. Note that the audio element begins relative to the video begin, and that the computed begin time is used, and not the observed begin time as constrained by the parent. Thus the audio begins 3 seconds into the media, and also lasts 5 seconds.
The behavior can be thought of as a clipBegin value applied to the element, that only applies to the first iteration of repeating elements. In the example above, if either element were defined to repeat, the second and later iterations of the media would play from the beginning of the media (see also the repeatCount, repeatDur, and repeat attributes: repeating elements).
This section is normative
The behavior can be thought of as a clipBegin value applied to the element, that only applies to the first iteration of repeating elements.
The element will actually begin at the time computed according to the following algorithm:
Let o be the offset value of a given begin value, d be the associated simple duration, AD be the associated active duration. Let rAt be the time when the begin time becomes resolved. Let rTo be the resolved sync-base or event-base time without the offset Let rD be rTo - rAt. If rD < 0 then rD is set to 0. If AD is indefinite, it compares greater than any value of o or ABS(o). REM( x, y ) is defined as x - (y * floor( x/y )). If y is indefinite or unresolved, REM( x, y ) is just x. Let mb = REM( ABS(o), d ) - rD
If ABS(o) >= AD then the element does not begin. Else if mb >= 0 then the media begins at mb. Else the media begins at mb + d.
If the element repeats, the iteration value of the
repeat event has the calculated value based upon the above
computed begin time, and not the observed number of repeats.
This section is informative
Thus for example:
<smil ...> ... <ref begin="foo.activateEvent-8s" dur="3s" repeatCount="10" .../> ... </smil>
The element begins when the user activates (for
example, clicks on) the element "foo". Its calculated begin time is actually
8 seconds earlier, and so it begins to play at 2 seconds into the 3 second
simple duration, on the third repeat iteration. One second later, the fourth
iteration of the element will begin, and the associated repeat
event will have the iteration value set to 3 (since it is zero based). The
element will end 22 seconds after the activation. The beginEvent
event is raised when the element begins, but has a time stamp value that
corresponds to the defined begin time, 8 seconds earlier. Any time dependents
are activated relative to the computed begin time, and not the observed begin
time.
Note: If script authors wish to distinguish
between the computed repeat iterations and observed repeat iterations, they
can count actual repeat events in the associated event
handler.
A begin time specifies a synchronization relationship between the element and the parent time container. Syncbase variants, eventbase, marker and wallclock timing are implicitly converted to an offset on the parent time container, just as an offset value specifies this directly. For children of a seq, the result is always a positive offset from the begin of the seq time container. However, for children of par and excl time containers the computed offset relative to the parent begin time may be negative.
Note that an element cannot actually begin until the parent time container begins. An element with a negative time delay behaves as if it had begun earlier. The presentation effect for the element (e.g. the display of visual media) is equivalent to that for a clipBegin value (with the same magnitude) for the first -- and only the first -- iteration of a repeated element. If no repeat behavior is specified, the element presentation effect of a negative begin offset is equivalent to a clipBegin specification with the same magnitude as the offset value. Nevertheless, the timing side effects are not equivalent to a clipBegin value as described. Time dependents of the begin value will behave as though the element had begun earlier.
The length of the simple duration is specified using the dur attribute. The dur attribute syntax is described below.
This section is normative
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 "media" attribute value is used on
an element that does not define media (e.g. on the SMIL 2.1 time container
elements par,
seq and excl), the attribute will be ignored
(as though it were not specified). Contained media such as the children of a
par are not considered media directly
associated with the element.
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. If the media element has no timed children, it is described as a simple media element.
If the author specifies a value for dur that is shorter than the implicit duration for an element, the implicit duration will be cut short by the specified simple duration.
If the author specifies a simple duration that is longer than the implicit duration for an element, the implicit duration of the element is extended to the specified simple duration:
Note that when the simple duration is "indefinite", some simple use cases can yield surprising results. See the related example #4 in Appendix B.
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.
<smil ...> ... <text id="show" ... /> <img begin="show.activateEvent" dur="3.5s" ... /> ... </smil ...>
This section is informative
SMIL 2.1 provides an additional control over the active duration. The end attribute allows the author to constrain the active duration by specifying an end value using a simple offset, a time base, an event-base, a syncbase, or DOM methods calls. The rules for combining the attributes to compute the active duration are presented in the section, Computing the active duration.
The normative syntax rules for each attribute value variant are described in the section Timing attribute value grammars; a syntax summary is provided here as an aid to the reader.
This section is normative
endElement() method call.If an end attribute is specified but none of dur, repeatCount and repeatDur are specified, the simple duration is defined to be indefinite, and the end value constrains this to define the active duration. The behavior of the simple duration in this case is defined in Dur value semantics, as though dur had been specified as "indefinite".
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.
The deprecated SMIL 1.0-syncbase-values are semantically equivalent to the following SMIL 2.1 end-value types:
id(Id-value)(begin) is equivalent to
Id-value.begin id(Id-value)(end) is equivalent to
Id-value.endid(Id-value)(Clock-value) is equivalent to
Id-value.begin+Clock-valueThis section is informative
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 the restart attribute).
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 duration. 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 an author wishes to specify the implicit duration as well as an end
constraint, the dur attribute can be
specified as "media". In the following example, the element will
end at the earlier of the intrinsic media duration, or a mouse click:
<html ...> ... <video dur="media" end="click" src="movie.mpg" .../> ... </html>
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 for end.
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 activates (e.g., clicks on) the "gobtn" element. The active duration will end 30 seconds after the parent time container begins.
<smil ...>
...
<par>
<audio src="music.au" begin="gobtn.activateEvent" repeatDur="indefinite"
end="30s" ... />
<img src="foo.jpg" dur="40s" ... />
</par>
...
</smil>
Note that if the user has not clicked on the target element before 30 seconds elapse, the element will never begin. In this case, the element has no active duration and no active end.
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.
<html ...> ... <img src="image.jpg" end="click" /> ... </html>
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.
<smil ...> ... <seq> <video dur="5s" repeatCount="3" end="activateEvent; next.activateEvent" .../> <video dur="5s" repeatCount="3" end="activateEvent; next.activateEvent" .../> <video dur="5s" repeatCount="3" end="activateEvent; next.activateEvent" .../> <video dur="5s" repeatCount="3" end="activateEvent; next.activateEvent" .../> <video dur="5s" repeatCount="3" end="activateEvent; next.activateEvent" .../> </seq> ... </smil>
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 is normative
This section is informative
The min/max attributes provide the author with a way to control the lower and upper bound of the element active duration.
This section is normative
If there is any error in the argument value syntax for min, the attribute will be ignored (as though it were not specified).
The default value for min is "0". This does not constrain the active duration at all.
If there is any error in the argument value syntax for max, the attribute will be ignored (as though it were not specified).
The default value for max is "indefinite". This does not constrain the active duration at all.
If the "media" argument value is specified
for either min or max on an element that does not define media
(e.g. on the SMIL 2.1 time container elements par, seq
and excl), the respective
attribute will be ignored (as though it were not specified). Contained media
such as the children of a par are not
considered media directly associated with the element.
If both min and max attributes are specified then the max value must be greater than or equal to the min value. If this requirement is not fulfilled then both attributes are ignored.
The rule to apply to compute the active duration of an element with min or max specified is the following: Each time the active duration of an element is computed (i.e. for each interval of the element if it begins more than once), this computation is made without taking into account the min and max attributes (by applying the algorithm described in Computing the active duration). The result of this step is checked against the min and max bounds. If the result is within the bounds, this first computed value is correct. Otherwise two situations may occur:
if the first computed duration is greater than the max value, the active duration of the element is defined to be equal to the max value (see the first example below).
if the first computed duration is less than the min value, the active duration of the element becomes equal to the min value and the behavior of the element is as follows :
if the repeating duration (or the simple duration if the element doesn't repeat) of the element is greater than min then the element is played normally for the (min constrained) active duration. (see the second and third examples below).
otherwise the element is played normally for its repeating duration (or simple duration if the element does not repeat) and then is frozen or not shown depending on the value of the fill attribute (see the fourth and fifth examples below).
This section is informative
The following examples illustrate some simple use cases for min and max attributes:
Example 1. In the following example, the video will only play for 10 seconds.
<smil ...> ... <par > <video id="video_of_15s" max="10s".../> </par> ... </smil>
Example 2. In the following example, if an activate event happens before 10 seconds, this activation (e.g. click) does not interrupt the video immediately, but the video plays until 10 seconds and then stops. If a click event happens after 10 seconds, the video plays (repeating) until the click happens. Note, the endEvent is only raised if a click occurs after 10 seconds, not at the simple end of each repeat.
<smil ...> ... <par > <video id="video_of_15s" repeatDur="indefinite" end="activateEvent" min="10s".../> </par> ... </smil>
Example 3. In the following example, if an activate event happens on element "foo" at 5 seconds, this event does not end the time container immediately, but rather at 12 seconds. The simple duration is defined to be "indefinite" (because an end attribute is specified with no dur attribute), and so the time container plays normally until it ends at 12 seconds.
<smil ...> ... <par end="foo.activateEvent" min="12s" > <video id="video_of_15s" .../> <video id="video_of_10s" .../> </par> ... </smil>
Example 4. In the following example, if a click event happens on the first video at 5 seconds, then the simple duration of the time container is computed as 5 seconds. Respecting the fill attribute in the time between the end of the simple duration and the end of the active duration, the two videos are frozen between 5 seconds and 12 seconds.
<html ...> ... <par endsync="first" min="12s" fill="freeze" > <video id="video_of_15s" end="click" ...> <video id="video_of_10s" .../> </par> ... </html>
Example 5. In the following example, the time container simple duration is
defined to be 5 seconds, and the min constraint defines the active duration
to be 12 seconds. Since the default value of fill in this case is "remove",
nothing is shown for the time container between 5 seconds and 12 seconds.
<par dur="5s" min="12s" > <video id="video_of_15s"/> <video id="video_of_10s" /> </par>
If an element is defined to begin before its parent (e.g. with a simple negative offset value), the min duration is measured from the calculated begin time not the observed begin (see example 1 below). This means that the min value may have no observed effect (as in example 2 below).
Example 1. In the following example, the image will be displayed from the beginning of the time container for 2 seconds.
<par> <img id="img" begin="-5s" min="7s" dur="5s" .../> </par>
Example 2. In the following example, the image will not be displayed at all.
<par> <img id="img" begin="-5s" min="4s" dur="2s" .../> </par>
See also the sections The min attribute and restart and Time container constraints on child durations.
This section is normative
The syntax specifications are defined using EBNF notation as defined in XML 1.1 [XML11]
In the syntax specifications that follow, allowed white space is indicated as "S", defined as follows (taken from the [XML11] definition for 'S'):
S ::= (#x20 | #x9 | #xD | #xA)+
This section is normative
A begin-value-list is a semi-colon separated list of timing specifiers:
begin-value-list ::= begin-value (S? ";"S? begin-value-list )? begin-value ::= (offset-value | syncbase-value | event-value | repeat-value | accesskey-value | media-marker-value | wallclock-sync-value | "indefinite" )
This section is normative
An end-value-list is a semi-colon separated list of timing specifiers:
end-value-list ::= end-value (S? ";"S? end-value-list )? end-value ::= (offset-value | syncbase-value | event-value | repeat-value | accesskey-value | media-marker-value | wallclock-sync-value | "indefinite" )
Several of the timing specification values have
a similar syntax. To parse an individual item
in a value-list, the following approach defines the correct
interpretation. In addition, Id-values and Event-symbols are XML NMTOKEN values and
as such are allowed to contain the full stop '.' and
hyphen-minus '-' characters. The reverse
solidus character '\' must be used to escape these characters within
Id-values
and Event-symbols, otherwise these characters will be interpreted as the
full stop separator and hyphen-minus sign, respectively. Once these rules are
interpreted, but before Id-values in syncbase values, event values, or
media-marker values are further handled, all leading and embedded escape
characters should be removed.
'+' or '-'), the value
should be parsed as an offset
value..' characters preceded by a reverse solidus
'\' escape character should not be treated as a separator,
but as a normal token 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.This approach allows implementations to treat the
tokens wallclock and
indefinite as reserved element IDs, and begin, end and marker as reserved event names, while retaining an
escape mechanism so that elements and events with those names may be
referenced.
Clock values have the following syntax:
Clock-value ::= ( Full-clock-value | Partial-clock-value | Timecount-value ) Full-clock-value ::= Hours ":" Minutes ":" Seconds ("." Fraction)? Partial-clock-value ::= Minutes ":" Seconds ("." Fraction)? Timecount-value ::= 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 millisecondsFractional 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
Offset values are used to specify when an element should begin or end relative to its syncbase.
This section is normative
An offset value has the following syntax:
offset-value ::= ( S? ("+" | "-") S? )? ( Clock-value )
The implicit syncbase for an offset value is dependent upon the time container:
Deprecated.
smil-1-syncbase-value ::= "id(" Id-value ")" ( "(" ( "begin" | "end" | Clock-value) ")" )?
This section is normative
ID reference values are references to the value of an "id" attribute of another element in the document.
Id-value ::= Id-ref-value
Id-ref-value ::= IDREF | Escaped-Id-ref-value
Escaped-Id-ref-value ::= Escape-Char NMTOKEN
Escape-Char ::= "\"
If the element referenced by the IDREF is ignored as described in the Content Control modules (e.g. if it specifies test attributes that evaluate false), the associated time value (i.e.. the syncbase value or the eventbase value that specifies the Id-value) will be considered invalid.
This section is informative
The semantics of ignored elements may change in a future version of SMIL. One possible semantic is that the associated sync arc arguments will not be invalid, but will instead always be "unresolved". When this behavior needs to be simulated in this version of SMIL Timing and Synchronization, an author can include the value "indefinite" in the list of values for the begin or end attribute.
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.
This section is normative
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"
The syncbase element is qualified with one of the following time symbols:
Examples
begin="x.end-5s" :
Begin 5 seconds before "x" ends
begin=" x.begin " : Begin when "x" begins
end="x.begin + 1min" : End 1 minute after "x"
begins
This section is informative
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.
This section is normative
An event value has the following syntax:
Event-value ::= (
Eventbase-element "." )? Event-symbol
( S? ("+"|"-") S? Clock-value )?
Eventbase-element ::= ID
The eventbase-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 eventbase timing is specified (the current element). A host language designer may override the definition of the default eventbase element. As an example of this, the SMIL 2.1 Animation modules describe Timing integration requirements for the animation elements (animate, animateMotion, etc.). These requirements specify that the default eventbase element is the target element of the animation. See SMIL 2 Animation section 3.9.1 (Integration requirements).
The event value must specify an Event-symbol. This term is an XML NMTOKEN that specifies the name of the event that is raised on the Event-base element. The host language designer must specify which events can be specified.
If an integrating language specifies no supported events, the event-base time value is effectively unsupported for that language.
A host language may choose not to include support for offsets with event values. The language must specify if this support is omitted.
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.
Unless explicitly specified by a host language, it is not considered an error to specify an event that cannot be raised on the Event-base element (such as activateEvent or click for audio or other non-visual elements). Since the event will never be raised on the specified element, the event-base value will never be resolved.
The last term specifies an optional offset-value that is an offset from the time of the event.
This section is informative
This module defines several events that may be
included in the supported set for a host language, including
beginEvent and endEvent. These should not be
confused with the syncbase time values. See the section on
Events and event model.
The semantics of event-based timing are detailed in Unifying Scheduling and Interactive Timing. Constraints on event sensitivity are detailed in Event sensitivity.
Examples:
begin=" x.load " :
Begin when "load" is observed on "x"
begin="x.focus+3s" : Begin 3 seconds after a "focus"
event on "x"
begin="x.endEvent+1.5s" : Begin 1 and a half seconds after an
"endEvent" event on "x"
begin="x.repeat" : Begin each time a
repeat event is observed on "x"
The following example describes a qualified repeat eventbase value:
<html ...> ... <video id="foo" repeatCount="10" end="endVideo.click" ... /> <img id="endVideo" begin="foo.repeat(2)" .../> ... </html>
The "endVideo" image will appear when the video "foo" repeats the second time. This example allows the user to stop the video after it has played though at least twice.
Repeat values are a variant on event values that
support a qualified repeat event. The repeat event defined in Events and event model allows an additional
suffix to qualify the event based upon an iteration value.
A repeat value has the following syntax:
Repeat-value ::= (
Eventbase-element "." )? "repeat(" iteration ")"
( S? ("+"|"-") S? Clock-value )?
iteration ::= DIGIT+
If this qualified form is used, the eventbase value will only be resolved when a repeat is observed that has a iteration value that matches the specified iteration.
The qualified repeat event syntax allows an author to respond only to an individual repeat of an element.
Accesskey values allow an author to tie a begin or end time to a particular key press, independent of focus issues. It is modeled on the HTML accesskey support. Unlike with HTML, user agents should not require that a modifier key (such as "ALT") be required to activate an access key.
An access key value has the following syntax:
Accesskey-value ::= "accesskey(" character
")" The character is a single character from [ISO10646].
( S? ("+"|"-") S? Clock-value )?
The time value is defined as the time that the access key character is input by the user.
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.
This section is normative
Media-Marker-value ::= Id-value ".marker(" S? marker-name S? ")"
This section is informative
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].
This section is normative
wallclock-sync-value ::= "wallclock(" S? (DateTime | WallTime | Date) 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 )
This section is informative
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.
This section is normative
There are three ways of handling time zone offsets:
The presentation engine must be able to convert wallclock-values to a time within the document.
This section is informative
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-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 )"
This section is normative
The endsync attribute controls the implicit duration of time containers, as a function of the children. The endsync attribute is only valid for par and excl time container elements, and media elements with timed children (e.g. animate or area elements). Integrating languages may allow the