Movatterモバイル変換

This section is normative

5.4.1 Changes for SMIL 3.0

This section is informative

This section remains largely unchanged for SMIL 3.0except for the relaxation of the restrictions on thebegin attributes of children of aseq time container. Also, a number of exampleshave been added.

The timing model is defined by building up from the simplest to the mostcomplex concepts: first the basic timing and simple duration controls,followed by the attributes that control repeating and constraining the activeduration. Finally, the elements that define time containers arepresented.

The time model depends upon several definitions for the host document: Ahost document is presented over a certain time interval.

5.4.3 Attributes

This section defines the set of timing attributes thatare common to all of the SMIL synchronization elements.

Unless otherwise specified below, if there is any errorin the argument value syntax for an attribute, the attribute will be ignored(as though it were not specified).

The beginanddur attributes: basic timingsupport

This section is informative

The basic timing for an element is described using thebegin anddur attributes. Authors may specify the begintime of an element in a variety of ways, ranging from simple clock times tothe time that an event (e.g. a mouse click) happens. The simple duration ofan element is specified as a simple time value. Thebegin attribute syntax is described below.

The normative syntax rules for each attribute value variant aredescribed inTimingattribute value grammars; an attribute value syntax summary isprovided here as an aid to the reader.

begin :SMIL-1-syncbase-value |Begin-value-list

Defines when the element becomes active.
The attribute value is either a SMIL 1.0 syncbase declaration, or a semi-colon separated list of values.

SMIL-1-syncbase-value: Deprecated. Describes a syncbase and an offset from that syncbase. The element begin is defined relative to the begin or active end of another element.
Begin-value-list : Begin-value (";" Begin-value-list )?: A semi-colon separated list of begin values. The interpretation of a list of begin times is detailed in the sectionEvaluation of begin and end time lists.
Begin-value : ( Offset-value | Syncbase-value | Event-value | Repeat-value | Accesskey-value | Media-Marker-value | Wallclock-sync-value | "indefinite" ): Describes the element begin.
Offset-value: Describes the element begin as an offset from an implicit syncbase. The definition of the implicit syncbase depends upon the element's parent time container. The offset is measured in parent simple time.
Syncbase-value: Describes a syncbase and an offset from that syncbase. The element begin is defined relative to the begin or active end of another element.
Event-value: Describes an event and an optional offset that determine the element begin. The element begin is defined relative to the time that the event is raised. Events may be any event defined for the host language in accordance with[DOM2Events]. These may include user-interface events, event-triggers transmitted via a network, etc. Details of event-based timing are described in the section below onUnifying Event-based and Scheduled Timing.
Repeat-value: Describes a qualified repeat event. The element begin is defined relative to the time that the repeat event is raised with the specified Iteration value.
Accesskey-value: Describes an accesskey that determines the element begin. The element begin is defined relative to the time that the accesskey character is input by the user.
Media-Marker-value: Describes the element begin as a named marker time defined by a media element.
Wallclock-sync-value: Describes the element begin as a real-world clock time. The wallclock time syntax is based upon syntax defined in[ISO8601].
"indefinite": The begin of the element will be determined by a "beginElement()" method call or a hyperlink targeted to the element.
The SMIL Timing and Synchronization DOM methods are described in theDOMTimingMethods section.
Hyperlink-based timing is described in theHyperlinks and timing section.

Begin value semantics

Children of aseq can only specify a non-negative offset value forbegin.
If nobegin is specified, the default timing is dependent upon the time container.
If there is a syntax error in any individual value in the list of begin or end values (i.e. the value does not conform to the defined syntax for any of the time values), the host language must specify how the user agent deals with this.
A time value may conform to the defined syntax but still be invalid (e.g. if an unknown element is referenced by ID in a syncbase value). If there is such an evaluation error in an individual value in the list of begin or end values, the individual value will be will be treated as though "indefinite" were specified, and the rest of the list will be processed normally. If no legal value is specified for a begin or end attribute, the element assumes an "indefinite" begin or end time (respectively).
The deprecatedSMIL-1-syncbase-values are semantically equivalent to the following SMIL 3.0 Begin-value types:
- id(Id-value)(begin) is equivalent toId-value.begin
- id(Id-value)(end) is equivalent toId-value.end
- id(Id-value)(Clock-value) is equivalent toId-value.begin+ Clock-value

This section is informative

Children of apar begin by defaultwhen thepar begins (equivalent tobegin="0s"). Children of aseq begin by default when the previous childends its active duration (equivalent tobegin="0s"); the firstchild begins by default when the parentseq begins. Children of anexcl default to a begin value of "indefinite".

Thebegin value may specify a listof times. This can be used to specify multiple "ways" or "rules" to begin anelement, e.g. if any one of several events is raised. A list of times mayalso 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 toactually be used - see also therestart attribute).

In general, the earliest time in the list determines the begin time of theelement. There are additional constraints upon the evaluation of the begintime list, detailed inEvaluation of begin and end timelists.

Note that while it is legal to include "indefinite" in a list of values forbegin, "indefinite" is only really useful as a single value.Combining it with other values does not impact begin timing, as DOM beginmethods may be called with or without specifying "indefinite" forbegin.

When a begin time is specified as a syncbase variant, a marker value or awallclock value, the defined time must be converted by the implementation toa time that is relative to the parent time container (i.e. to the equivalentof an offset value). This is known astimespace conversion, and isdetailed in the sectionConverting between local and globaltimes.

Handling negative offsets for begin

For children of<par> and<excl> time containers, the computed offset relative to the parent begin time may be negative.
A begin time may be specified with a negative offset relative to an event or to a syncbase that is not initially resolved. When the syncbase or eventbase time is resolved, the computed time may be in the past.

The computed begin time defines thescheduled synchronizationrelationship of the element, even if it is not possible to begin theelement 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

The use of negative offsets to define begin timesmerely defines the synchronization relationship of the element. It does notin any way override the time container constraints upon the element, and itcannot override the constraints of presentation time.

If an element has a begin time that resolves to a time before the parenttime container begins, the parent time container constraint still applies.For example:

<par>   <video xml:id="vid" begin="-5s" dur="10s" src="movie.mpg" />   <audio begin="vid.begin+2s" dur="8s" src="sound.au" /></par>

Thevideo element cannot beginbefore thepar begins. The begin issimply defined to occur"in the past" when thepar begins. The viewer will observe that thevideo begins 5 seconds into the media, and ends after 5 seconds. Note thatthe audio element begins relative to the video begin, and that the computedbegin time is used, and not the observed begin time as constrained by theparent. Thus the audio begins 3 seconds into the media, and also lasts 5seconds.

The behavior can be thought of as aclipBegin value applied to the element,that only applies to the first iteration of repeating elements. In theexample above, if either element were defined to repeat, the second and lateriterations of the media would play from the beginning of the media (see alsotherepeatCount,repeatDur, andrepeat attributes: repeating elements).

When a begin time is resolved to be in the past (i.e., before the current presentation time), the element begins immediately, but acts as though it had begun at the specified time (playing from an offset into the media).

This section is informative

The behavior can be thought of as aclipBegin 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 thefollowing algorithm:

Leto be the offset value of a given begin value,d be the associated simple duration,AD be the associated active duration.LetrAt be the time when the begin time becomes resolved.LetrTo be the resolved sync-base or event-base time without the offsetLetrD berTo - rAt.  IfrD < 0 thenrD is set to0. IfAD is indefinite, it compares greater than any value ofo orABS(o).REM( x, y ) is defined asx - (y * floor( x/y )). If y is indefinite or unresolved,REM( x, y ) is justx.Letmb = REM( ABS(o), d ) - rD

IfABS(o) >= ADthen the element does not begin.Else ifmb >= 0 then the media begins atmb.Else the media begins atmb + d.

If the element repeats, the Iteration value of therepeatevent has the calculated value based upon the above computed begin time, andnot 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) theelement "foo". Its calculated begin time is actually 8 seconds earlier, andso it begins to play at 2 seconds into the 3 second simple duration, on thethird repeat iteration. One second later, the fourth iteration of the elementwill begin, and the associatedrepeat event will have theIteration value set to 3 (since it is zero based). The element will end 22seconds after the activation. ThebeginEvent event is raisedwhen the element begins, but has a time stamp value that corresponds to thedefined begin time, 8 seconds earlier. Any time dependents are activatedrelative to the computed begin time, and not the observed begin time.

Note: If script authors wish to distinguish between the computed repeatiterations and observed repeat iterations, they can count actualrepeat events in the associated event handler.

Negative begin delays

This section is informative

A begin time specifies a synchronization relationshipbetween the element and the parent time container. Syncbase variants,eventbase, marker and wallclock timing are implicitly converted to an offseton the parent time container, just as an offset value specifies thisdirectly. For children of aseq,the result is always a positive offset from the begin of theseq time container. However, forchildren ofpar andexcl time containers the computedoffset relative to the parent begin time may be negative.

Note that an element cannot actually begin until the parent time containerbegins. An element with a negative time delay behavesas if it had begun earlier.

The presentation effect for the element (e.g. thedisplay of visual media) is equivalent to that for aclipBegin value (with the samemagnitude) for the first -- and only the first -- iteration of a repeatedelement. If no repeat behavior is specified, the element presentation effectof a negative begin offset is equivalent to aclipBegin specification with the samemagnitude as the offset value. Nevertheless, thetiming side effectsarenot equivalent to aclipBegin value as described. Timedependents of the begin value will behave as though the element had begunearlier.

Dur value semantics

The length of the simple duration is specified usingthedur attribute. Thedur attribute syntax is described below.

dur

Specifies the simple duration.
The attribute value may be any of the following:

Clock-value: Specifies the length of the simple duration, measured in element active time.
Value must be greater than 0.
"media": Specifies the simple duration as the intrinsic media duration. This is only valid for elements that define media.
"indefinite": Specifies the simple duration as indefinite.

If there is any error in the argument value syntax fordur, the attribute will be ignored (as thoughit were not specified).

If the "media" attribute value is used on an element thatdoes not define media (e.g. on the SMIL 3.0 time container elementspar,seqandexcl), the attribute will beignored (as though it were not specified). Contained media such as thechildren of apar are not consideredmedia directly associated with the element.

If the element does not have a (valid)dur attribute, the simple duration for theelement is defined to be the implicit duration of the element.

This section is informative

The implicit duration depends upon the type of anelement. The primary distinction is between different types of media elementsand time containers. If the media element has no timed children, it isdescribed as asimple media element.

For simple media elements that specify continuous media (i.e. media with an inherent notion of time), the implicit duration is the intrinsic duration of the media itself - e.g. video and audio files have a defined duration.
This comment is informative.
Note thatclipBegin andclipEnd attributes on a media element may override the intrinsic media duration, and will define the implicit duration. See also theMedia Object module.
For simple media elements that specify discrete media (some times referred to as "static" media), the implicit duration is defined to be 0.
This comment is informative.
Forpar,seq andexcl time containers, and media elements that are also time containers, the implicit simple duration is a function of the type of the time container and of itsendsync attribute. For details see the sectionTime container durations.

If the author specifies a value fordur that isshorter than the implicitduration for an element, the implicit duration will be cut short by thespecified simple duration.

If the author specifies a simple duration that islonger than theimplicit duration for an element, the implicit duration of the element isextended to the specified simple duration:

For a discrete media element, the media will be shown for the specified simple duration.
For a continuous media element, the ending state of the media (e.g. the last frame of video) will be shown from the end of the intrinsic media duration to the end of the specified simple duration. This only applies to visual media - aural media will simply stop playing (i.e. be silent).
For a seq time container, the last child is frozen until the end of the simple duration of the seq if and only if its fill behavior is "freeze" or "hold" (otherwise the child just ends without freezing).
Children of a par or excl are frozen until the end of the simple duration of the par or excl if and only if the children's fill behavior is "freeze" or "hold" (otherwise the children just ends without freezing).

This section is informative

Note that when the simple duration is"indefinite", some simple use cases can yieldsurprising results. See the relatedexample #4 in Appendix B.

Examples

This section is informative

The following example shows simple offset begin timing. The<audio>element begins 5 seconds afterthe<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 xml:id="song1" src="song1.au" />   <img src="img1.jpg" begin="song1.begin+2s" /></par>

Elements may also be specified to begin in response to an event. In thisexample, 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 xml:id="show" ... /><img begin="show.activateEvent" dur="3.5s" ... />...</smil>

The endattribute: controlling active duration

SMIL 3.0 provides an additional control over the active duration. Theend attribute allows the author toconstrain the active duration by specifying an end value using a simpleoffset, a time base, an event-base, a syncbase, or DOM methods calls. Therules for combining the attributes to compute the active duration arepresented in the section,Computing theactive duration.

The normative syntax rules for each attribute value variant are describedin the sectionTiming attributevalue grammars; a syntax summary is provided here as an aid to thereader.

end :SMIL-1-syncbase-value |End-value-list

Defines an end value for the element that may constrain the active duration.
The attribute value is either a SMIL 1.0 syncbase declaration, a semi-colon separated list of values.

SMIL-1-syncbase-value: Deprecated. Describes a syncbase and an offset from that syncbase. The end value is defined relative to the begin or active end of another element.
End-value-list : End-value (";" End-value-list )?: A semi-colon separated list of end values. The interpretation of a list of end times is detailed in the sectionEvaluation of begin and end time lists.
End-value : ( Offset-value | Syncbase-value | Event-value | Repeat-value | Accesskey-value | Media-Marker-value | Wallclock-sync-value | "indefinite" ): Describes the end value of the element.
Offset-value: Describes the end value as an offset from an implicit syncbase. The definition of the implicit syncbase depends upon the element's parent time container. The offset is measured in parent simple time.
Syncbase-value: Describes a syncbase and an offset from that syncbase. The end value is defined relative to the begin or active end of another element.
Event-value: Describes an event and an optional offset that determine the end value. The end value is defined relative to the time that the event is raised. Events may be any event defined for the host language in accordance with[DOM2Events]. These may include user-interface events, event-triggers transmitted via a network, etc. Details of event-based timing are described in the section below onUnifying Event-based and Scheduled Timing.
Repeat-value: Describes a qualified repeat event. The end value is defined relative to the time that the repeat event is raised with the specified Iteration value.
Accesskey-value: Describes an accesskey that determines the end value. The end value is defined as the time that the accesskey character is input by the user.
Media-Marker-value: Describes the end value as a named marker time defined by a media element.
Wallclock-sync-value: Describes the end value as a real-world clock time. The wallclock time is based upon syntax defined in[ISO8601].
"indefinite": The end value of the element will be determined by anendElement() method call.
The SMIL Timing and Synchronization DOM methods are described in theDOMTimingMethods section.

This section is informative

If anendattribute is specified but none ofdur,repeatCount andrepeatDur are specified, the simpleduration is defined to be indefinite, and the end value constrains this todefine the active duration. The behavior of the simple duration in this caseis defined inDur value semantics, asthoughdurhad been specified as"indefinite".

If theend valuebecomes resolved while the element is still active, and the resolved time isin the past, the element should end the active duration immediately. Timedependents defined relative to the end of this element should be resolvedusing the computed active end (which may be in the past), and not theobserved active end.

The deprecatedSMIL-1-syncbase-values are semantically equivalent to the following SMIL 3.0End-value types:

id(Id-value)(begin) is equivalent toId-value.begin
id(Id-value)(end) is equivalent toId-value.end
id(Id-value)(Clock-value) is equivalent toId-value.begin+Clock-value

This section is informative

Theend value may specify alist 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 listof times may also define multiple end times that may correspond tomultiple begin times, allowing the element to play more than once(this behavior can be controlled - see also therestart attribute).

In the following example, thedurattribute is not specified, and so the simple duration is defined to be theimplicit media duration. In this case (and this case only) the value ofend will extend the active duration if itspecifies a duration greater than the implicit duration. The video will beshown 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 endconstraint, thedur attribute may bespecified as "media". In the following example, the element willend at the earlier of the intrinsic media duration, or a mouse click:

<smil ...>...<video dur="media" end="activateEvent" src="movie.mpg" .../>...</smil>

These cases arise from the use of negative offsets in the sync-base andevent-base forms, and authors should be aware of the complexities this canintroduce. See alsoHandling negative offsetsfor end.

In the following example, the active duration will end at the earlier of10 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, andwill cut short the simple duration defined to be 20 seconds. The effect isthat only the first half of the element is actually played. For a simplemedia element, the author could just specify this using the dur attribute.However in other cases, it is sometimes important to specify the simpleduration 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 30seconds 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 30seconds elapse, the element will never begin. In this case, the element hasno active duration and no active end.

The defaults for the event syntax make it easy to define simpleinteractive behavior. The following example stops the image when the userclicks on the element.

<smil ...>...<img src="image.jpg"end="activateEvent" />...</smil>

Usingend with an event value enablesauthors to end an element based on either an interactive event or a maximumactive duration. This is sometimes known aslazy interaction.

In this example, a presentation describes factory processes. Each step isa video, and set to repeat 3 times to make the point clear. Each element mayalso be ended by clicking on the video, or on some element "next" thatindicates 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 earlierof 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 afaster pace.

Handling negative offsets for end

An end time may be specified with a negative offset relative to an event or to a syncbase that is not initially resolved.
When the syncbase or eventbase time is resolved, the computed time may be in the past.
The computed time defines thescheduled synchronization relationship of the element, even if it is not possible to end the element at the computed time.
When an end time is defined to be in the past, the element ends immediately. The defined end time is the computed time, and not the observed or performed time of the element end.

The min and maxattributes: more control over the active duration

The min/max attributes provide the author with a wayto control the lower and upper bound of the element activeduration.

min

Specifies the minimum value of the active duration.
The attribute value may be either of the following:

Clock-value: Specifies the length of the minimum value of the active duration, measured in element active time.
Value must be greater than or equal to 0.
"media": Specifies the minimum value of the active duration as the intrinsic media duration. This is only valid for elements that define media.

If there is any error in the argument value syntax formin, the attribute will be ignored (as thoughit were not specified).

The default value formin is "0".This does not constrain the active duration at all.

max

Specifies the maximum value of the active duration.
The attribute value may be either of the following:

Clock-value: Specifies the length of the maximum value of the active duration, measured in element active time.
Value must be greater than 0.
"media": Specifies the maximum value of the active duration as the intrinsic media duration. This is only valid for elements that define media.
"indefinite": The maximum value of the duration is indefinite, and so is not constrained.

If there is any error in the argument value syntax formax, the attribute will be ignored (as thoughit were not specified).

The default value formax is"indefinite". This does not constrain the active duration at all.

If the "media" argument value is specified for eithermin ormax on an element that does not define media(e.g. on the SMIL 3.0 time container elementspar,seqandexcl), the respective attributewill be ignored (as though it were not specified). Contained media such asthe children of apar are not consideredmedia directly associated with the element.

If bothmin andmax attributes are specified then themax value must be greater than or equal to themin value. If this requirement is notfulfilled then both attributes are ignored.

The rule to apply to compute the active duration of an element withmin ormax specified is the following: Each time theactive duration of an element is computed (i.e. for each interval of theelement if it begins more than once), this computation is made without takinginto account themin andmax attributes (by applying the algorithmdescribed inComputing the activeduration). The result of this step is checked against themin andmax bounds. If the result is within thebounds, this first computed value is correct. Otherwise two situations mayoccur:

if the first computed duration is greater than the max value, the active duration of the element is defined to be equal to themax value (see the first example below).
if the first computed duration is less than themin value, the active duration of the element becomes equal to themin 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 thanmin 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 thefill attribute (see the fourth and fifth examples below).

This section is informative

The following examples illustrate some simple use cases formin andmax attributes:

Example 1. In the following example, the video will only play for 10seconds.

<smil ...>...<par >   <video xml:id="video_of_15s"max="10s".../></par>...</smil>

Example 2. In the following example, if an activate event happens before10 seconds, this activation (e.g. click) does not interrupt the videoimmediately, but the video plays until 10 seconds and then stops. If a clickevent happens after 10 seconds, the video plays (repeating) until the clickhappens. Note, the endEvent is only raised if a click occurs after 10seconds, not at the simple end of each repeat.

<smil ...>...<par >   <video xml:id="video_of_15s" repeatDur="indefinite" end="activateEvent"min="10s".../></par>...</smil>

Example 3. In the following example, if an activate event happens onelement "foo" at 5 seconds, this event does not end the time containerimmediately, but rather at 12 seconds. The simple duration is defined to be"indefinite" (because anend attributeis specified with nodur attribute), andso the time container plays normally until it ends at 12 seconds.

<smil ...>...<par end="foo.activateEvent"min="12s" >   <video xml:id="video_of_15s" .../>   <video xml:id="video_of_10s" .../></par>...</smil>

Example 4. In the following example, if a click event happens on the firstvideo at 5 seconds, then the simple duration of the time container iscomputed as 5 seconds. Respecting thefill attribute in the time between the end ofthe simple duration and the end of the active duration, the two videos arefrozen between 5 seconds and 12 seconds.

<smil ...>...<par endsync="first" min="12s" fill="freeze" >   <video xml:id="video_of_15s" end="activateEvent" ...>   <video xml:id="video_of_10s" .../></par>...</smil>

Example 5. In the following example, the time container simple duration isdefined to be 5 seconds, and the min constraint defines the active durationto be 12 seconds. Since the default value offill in this case is"remove",nothing is shown for the time container between 5 seconds and 12 seconds.

<par dur="5s" min="12s" >   <video xml:id="video_of_15s" .../>   <video xml:id="video_of_10s" .../></par>

The min attribute and negative begin times

This section is informative

If an element is defined to begin before its parent (e.g. with a simplenegative offset value), themin durationis measured from the calculated begin time not the observed begin (seeexample 1 below). This means that themin value may have no observed effect (as inexample 2 below).

Example 1. In the following example, the image will be displayed from thebeginning of the time container for 2 seconds.

<par>    <img xml:id="img" begin="-5s" min="7s" dur="5s" .../></par>

Example 2. In the following example, the image will not be displayed atall.

<par>   <img xml:id="img" begin="-5s" min="4s" dur="2s" .../></par>

Timing attribute value grammars

The syntax specifications are defined using EBNF notation as defined inXML 1.1[XML11]

In the syntax specifications that follow, allowed white space is indicatedas "S", defined as follows (taken from the[XML11] definition for 'S'):

S ::= (#x20 | #x9 | #xD | #xA)+

Begin values

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" )

End values

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" )

Parsing timing specifiers

Several of the timing specification values have a similar syntax. Toparse an individual item in a value-list, the following approach defines thecorrect interpretation. In addition,Id-values andEvent-symbols are XML NMTOKEN values andas such are allowed to contain the full stop '.' andhyphen-minus '-' characters. The reverse solidus character '\' must be usedto escape these characters withinId-values andEvent-symbols, otherwise these characterswill be interpreted as the full stop separator and hyphen-minus sign,respectively. Once these rules are interpreted, but before Id-values insyncbase values, event values, or media-marker values are further handled,all leading and embedded escape characters should be removed.

Strip any leading, trailing, or intervening white space characters.
If the value begins with a number or numeric sign indicator (i.e.'+' or'-'), the value should be parsed as anoffset value.
Else if the value begins with the unescaped token "wallclock", it should be parsed as aWallclock-sync-value.
Else if the value is the unescaped token "indefinite", it should be parsed as the value "indefinite".
Else: Build a token substring up to but not including any sign indicator (i.e. strip off any offset, parse that separately, and add it to the result of this step). In the following, any '.' characters preceded by a reverse solidus '\' escape character should not be treated as a separator, but as a normal token character.
1. If the token contains no '.' separator character, then the value should be parsed as anEvent-value with an unspecified (i.e. default) eventbase-element.
2. Else if the token ends with the unescaped string ".begin" or ".end", then the value should be parsed as aSyncbase-value.
3. Else if the token contains the unescaped string ".marker(", then the value should be parsed as aMedia-Marker-value.
4. Else, the value should be parsed as anEvent-value (with a specified eventbase-element).

This section is informative

This approach allows implementations to treat thetokenswallclock andindefinite as reserved element IDs, andbegin,end andmarker as reserved event names, while retaining anescape mechanism so that elements and events with those names may bereferenced.

Clock values

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              ::=DIGITDIGITDIGIT               ::= [0-9]

For Timecount values, the default metric suffix is "s" (for seconds).

This section is informative

No embedded white space is allowed in clock values,although leading and trailing white space characters will beignored.

The following are examples of legal clock values:

Full clock values:02:30:03= 2 hours, 30 minutes and 3 seconds
50:00:10.25= 50 hours, 10 seconds and 250 milliseconds
Partial clock value:02:33= 2 minutes and 33 seconds
00:10.5= 10.5 seconds = 10 seconds and 500 milliseconds
Timecount values:
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 pointdefinitions of seconds. The number of digits allowed is unlimited (althoughactual precision may vary among implementations).

This section is informative

For example:

00.5s = 500 milliseconds00:00.005 = 5 milliseconds

Offset values

This section is informative

Offset values are used to specify when an elementshould begin or end relative to its syncbase.

An offset value has the following syntax:

Offset-value   ::= (S? ("+" | "-")S? )? (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 parent simple time.

The implicit syncbase for an offset value is dependent upon the timecontainer:

For children of a<par> or an<excl>, the offset is relative to the begin of the parent<par> or<excl>.
For children of a<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 alsoThe seq time container.

SMIL 1.0 begin and endvalues

This section is informative

Deprecated.

SMIL-1-syncbase-value  ::=SMIL-1-Id-value                           ( "(" ( "begin" | "end" |Clock-value) ")" )?SMIL-1-Id-value        ::= "id("Idref ")"

ID-Reference values

ID reference values are references to the value of an "id" attribute ofanother element in the document.

Id-value                   ::=Id-ref-valueId-ref-value               ::=Idref |Escaped-Id-ref-valueIdref                      ::= NameEscaped-Id-ref-value       ::=Escape-Char? NameStartChar (Escape-Char? NameChar)*Escape-Char                ::= "\"

The symbolsName,NameStartChar andNameChar are defined in XML 1.1[XML11].
TheIdref is a legal XML identifier.
If the Id-ref-value is not an Idref, then it is treated as an Escaped-ID-ref-value.
The Escaped-Id-ref-value allows the use of a SMIL 3.0 reserved symbol as an Idref value for an attribute by prefixing the reserved symbol with a backslash character. In this case the value should be treated as an Idref and not as the reserved symbol, and the leading backslash is significant in the parsing as detailed in the section onparsing XML identifiers in begin and end values.
Single characters may also be escaped by using the backslash character, and the character, minus the backslash, should be treated as a literal part of the NMTOKEN.

If the element referenced by the Idref is ignored as described in theContent Control modules (e.g. if it specifies test attributes that evaluatefalse), the associated time value (i.e.. the syncbase value or the eventbasevalue that specifies the Id-value) will be considered invalid.

This section is informative

The semantics of ignored elements may change in afuture version of SMIL. One possible semantic is that the associated sync arcarguments will not be invalid, but will instead always be "unresolved". Whenthis behavior needs to be simulated in this version of SMIL Timing andSynchronization, an author may include the value "indefinite" in the list ofvalues for the begin or end attribute.

Syncbase values

A syncbase value starts with a Syncbase-element termdefining the value of an "id" attribute of another element referred to as thesyncbase element.

A syncbase value has the following syntax:

Syncbase-value   ::= (Syncbase-element "."Time-symbol )                      (S? ("+"|"-")S?Clock-value )?Syncbase-element ::=Id-valueTime-symbol      ::= "begin" | "end"

The syncbase element must be another timed element contained in the host document.
The syncbase element may not be a descendant of the current element.
If the syncbase element specification refers to an illegal element, the time-value description will be treated as though "indefinite" were specified.

The syncbase element is qualified with one of the followingtimesymbols:

begin: Specifies the begin time of the syncbase element.
end: Specifies the Active End of the syncbase element.

The time symbol may 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 parent simple time.
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.

This section is informative

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

Event values

An Event value starts with an Eventbase-element termthat specifies theevent-base element. The event-base element is theelement on which the event is observed. Given DOM event bubbling, theevent-base element may be either the element that raised the event, or it maybe an ancestor element on which the bubbled event may be observed. Refer toDOM-Level2-Events[DOM2Events] for details.

An event value has the following syntax:

Event-value       ::= (Eventbase-element "." )?Event-symbol                        (S? ("+"|"-")S?Clock-value )?Eventbase-element ::=Id-valueEvent-symbol      ::= Nmtoken

The symbolNmtoken is defined in XML 1.1[XML11].

The eventbase-element must be another element contained in the hostdocument.

If the Eventbase-element term is missing, the event-base element defaultsto the element on which the eventbase timing is specified (the currentelement). A host language designer may override the definition of the defaulteventbase element. As an example of this, theSMIL 3.0 Animation modules describe Timingintegration requirements for the animation elements (animate, animateMotion,etc.). These requirements specify that the default eventbase element is thetarget element of the animation. See the sectionCommon Animation Integration Requirements.

The event value must specify an Event-symbol. This term is an XML NMTOKENthat specifies the name of the event that is raised on the Event-baseelement. The host language designer must specify which events may bespecified.

Host language specifications must include a description of legal event names (with "none" as a valid description), and/or allow any name to be used.
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 fromthe time of the event.

The offset is measured in parent simple time. 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.

This section is informative

This module defines several events that may be included in the supportedset for a host language, includingbeginEvent andendEvent. These should not be confused with the syncbase timevalues. See the section on Events and event model.

The semantics of event-based timing are detailed inUnifying Scheduling and InteractiveTiming. 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" eventon "x"
begin="x.endEvent+1.5s": Begin 1 and a half seconds after an"endEvent" event on "x"
begin="x.repeat": Begin each time arepeatevent is observed on "x"

The following example describes a qualified repeat eventbase value:

<smil ...>...<video xml:id="foo" repeatCount="10" end="endVideo.activateEvent" ... /><img xml:id="endVideo"begin="foo.repeat(2)" .../>...</smil>

The "endVideo" image will appear when the video "foo" repeats the secondtime. This example allows the user to stop the video after it has playedthough at least twice.

Repeat values

Repeat values are a variant on event values thatsupport a qualified repeat event. Therepeat event defined inEvents and event model allows an additionalsuffix 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 resolvedwhen a repeat is observed that has an Iteration value that matches thespecified iteration.

This section is informative

The qualified repeat event syntax allows an author torespond only to an individual repeat of an element.

Accesskey values

Accesskey values allow an author to tie a begin or endtime to a particular key press, independent of focus issues. It is modeled onthe HTML accesskey support. Unlike with HTML, user agents should not requirethat a modifier key (such as "ALT") be required to activate an access key.

An access key value has the following syntax:

Accesskey-value  ::= "accesskey(" Char ")"                       (S? ("+"|"-")S?Clock-value )?

TheChar symbol is defined in XML 1.1[XML11].

The time value is defined as the time that the access key character isinput by the user.

Media marker values

This section is informative

Certain types of media can have associatedmarker values that associate a name with a particular point (i.e. atime) in the media. The media marker value provides a means of defining abegin or end time in terms of these marker values. Note that if thereferenced id is not associated with a media element that supports markers,or if the specified marker name is not defined by the media element, theassociated time may never be resolved.

Media-Marker-value ::=Id-value ".marker("S?Marker-nameS? ")"Marker-name        ::= (Char - ")")+

TheChar symbol is defined in XML 1.1[XML11].
TheMarker-name symbol is a string that must conform to the definition of marker names for the media associated with the Id-value.

Wallclock-sync values

Wallclock-sync values have the following syntax. Thevalues allowed are based upon several of the "profiles" described in[DATETIME], which is based upon[ISO8601].

Wallclock-sync-value  ::= "wallclock("S? (DateTime |WallTime |Date)S? ")"DateTime       ::=Date "T"WallTimeDate           ::=Years "-"Months "-"DaysWallTime       ::= (HHMM-Time |HHMMSS-Time)(TZD)?HHMM-Time      ::=Hours24 ":"MinutesHHMMSS-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         ::=DIGITDIGITDIGITDIGITTZD            ::= "Z" | (("+" | "-")Hours24 ":"Minutes )

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].

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 asecond

   YYYY-MM-DDThh:mm:ss.sTZD (e.g. 1997-07-16T19:20:30.45+01:00)

Note that theMinutes,Seconds,Fraction,2DIGIT andDIGIT syntax is asdefined forClock-values. Note thatwhite space is not allowed within the date and time specification.

There are three ways of handling time zone offsets:

Times are expressed in UTC (Coordinated Universal Time), with a special UTC designator ("Z").
Times are expressed in local time, together with a time zone offset in hours and minutes. A time zone offset of "+hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes ahead of UTC. A time zone offset of "-hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes behind UTC.
Times are expressed in local time, as defined for the presentation location. The local time zone of the end-user platform is used.

This section is informative

The presentation engine must be able to convertwallclock-values to a time within the document.

When the document begins, the current wallclock time must be noted - this is thedocument 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.
Date wallclock values are treated as a DateTime value of the given date at time 00:00:00.00 in the local time zone.
WallTime values are treated as a DateTime value on the date of thedocument wallclock begin at the given time. Specified time zones must be respected, and the time converted into the local time zone before applying thedocument wallclock begin.

This section is informative

Note that the resulting begin or end time may bebefore the begin, or after end of the parent time container. This is not anerror, but thetime containerconstraints still apply. In any case, the semantics of thebegin andend attribute govern the interpretation of thewallclock value.

Examples

This section is informative

The following examples all specify a begin at midnight on January 1st2000, 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 July28th 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 thedocument is presented:

begin="wallclock( 08:00 )"

The endsync attribute

Theendsyncattribute controls the implicit duration of time containers, as a function ofthe children. Theendsync attributeis only valid forpar andexcl time container elements, and mediaelements with timed children (e.g.animate orarea elements). Integrating languages mayallow theendsync attribute on anyelement with time container semantics.

This section is informative

Theendsyncattribute is particularly useful with children that have "unknown" duration,e.g. an MPEGmovie, that must be played through to determine the duration, orelements with event-based end timing.

Legal values for the attribute are:

first: Thepar,excl, or media element's implicit duration ends with the earliest active end of all the child elements. This does not refer to the lexical first child, or to the first child to start, but rather refers to the first child to end its (first) active duration.
last: Thepar,excl, or media element's implicit duration ends with the last active end of the child elements. This does not refer to the lexical last child, or to the last child to start, but rather refers to the last active end of all children that have a resolved, definite begin time. If the time container has no children with a resolved begin time, the time container ends immediately. If child elements have multiple begin times, or otherwise restart, the child elements must completeall instances of active durations for resolved begin times (seeThe instance times lists).
This is the default value forpar andexcl elements.
all: Thepar,excl, or media element's implicit duration ends when all of the child elements have ended their respective active durations. Elements with indefinite or unresolved begin timeswillkeep the simple duration of the time container from ending.
When all elements have completed the active duration one or more times, the parent time container may end.
media: The time container element's implicit duration ends when the intrinsic media duration of the element ends. This must be defined by a host language. If the time container element does not define an intrinsic media duration, the host language must define the simple duration for the element.
This is the default value for media time container elements.
Id-value: Thepar,excl, or media element time container's implicit duration ends when the specified child ends its (first) active duration. The id must correspond to one of the immediate timed children of the time container.
SMIL-1-Id-value: This is a SMIL 1.0 identifier value of the form "id("Idref ")". The semantics are identical to those of the Id-value immediately above. This syntax is deprecated.

Elements may have an unresolved or indefinite begin time when the parent begins. If an element's unresolved begin time becomes resolved (and definite) before the parent time container ends the simple duration, the element must be considered by theendsync="last" semantics.
This comment is informative.
This may chain, so that only one element is running at one point, but before it ends its active duration another interactive element is resolved. It may even yield "dead time" (where nothing is playing), if the resolved begin isafter the other elements active end.
If theendsync semantics consider any child that has an unresolved active duration, then the implicit duration of the time container is also unresolved.
For theId-value arg-value variant, the referenced child may have an unresolved begin time. If this causes the active end time to be unresolved as well, the implicit duration of the time container is also unresolved.
If theendsync semantics consider any child that has a (resolved) indefinite active duration, then the implicit duration of the time container is also indefinite.
Media element time containers define an intrinsic duration equal to the duration of the referenced media.
This comment is informative.
If the referenced media is not continuous, the duration is 0 (endsync="media"will not generally be useful on discrete media).
If themedia argument value is used for an element that does not declare media, the attribute is ignored (as thoughendsync had not been specified).
If theId-value arg-value variant is not an immediate child of the time container, it is as ifendsync is not specified.
For the purpose of parsing theendsync argument value,first,last,all, andmedia are reserved words and must be escaped with a backslash in order to be used asId-value's.

Semantics ofendsync anddur andend:

If an element specifies bothendsync anddur, theendsync attribute is ignored. The element's simple duration is defined by the value ofdur.
If an element specifies bothendsync andend, but none ofdur,repeatDur orrepeatCount, theendsync attribute is ignored. In this case the element behaves as if only end were specified, therefore the element's implicit duration is indefinite and will be constrained by theend value.

Semantics ofendsync andrestart:

In the case of an element that restarts (e.g. because of multiple begin times), the element is considered to have ended its active duration when one active duration instance has completed. It is not a requirement that all instances associated with multiple begin and end times complete, to satisfy the semantics ofendsync. This means that if the element is playing a second or later instance of an active duration, it may be cut short by a parent, once the other children satisfy theendsync semantics.

Semantics ofendsync and paused elements:

Note that child elements of anexcl that are currently paused (by theexcl semantics) have not ended their active duration. Similarly, any element paused via the DOMpause() method has not completed its active duration. Paused elements (that have not already completed the active duration at least once) must be considered in the evaluation ofendsync.
This comment is informative.
For example, if a time container withendsync="last" has paused child elements, the simple duration of the time container will not end until the paused children resume or otherwise end.

This section is informative

Semantics ofendsync andunresolved child times:

endsync="first" means that the element must wait for any child element to actually end its active duration. It does not matter whether the first element to end was scheduled or interactive.
endsync="last" means that the element must wait for all child elements that have a resolved begin, to end the respective active durations.
Elements with indefinite or unresolved begin times willnotkeep the simple duration of the time container from ending. If there are no children with a resolved begin time, the time container will end immediately.
Elements with a resolved begin time but indefinite or unresolved end timeswillkeep the simple duration of the time container from ending.
endsync="all" means that the element must wait for the end of every child element's active duration.
endsync=[Id-value] means that the element must wait for the referenced element to actually end its active duration.

The following pseudo-code describes theendsync algorithm:

// // boolean timeContainerHasEnded()//// method on time containers called to evaluate whether// time container has ended, according to the rules of endsync.// Note: Only supported on par and excl//// A variant on this could be called when a child end is updated to// create a scheduled (predicted) end time for the container.//// Note that we never check the end time of children - it doesn't matter.//// Assumes: //     child list is stable during evaluation//     isActive state of children is up to date for current time.//      [In practice, this means that the children must all be//        pre-visited at the current time to see if they are done.//        If the time container is done, and repeats, the children//        may be resampled at the modified time.]////   Uses interfaces: //   on TimedNode://     isActive()             tests if node is currently active//     hasStarted()           tests if node has (ever) begun//     begin and end          begin and end TimeValues of node////   on TimeValue         (a list of times for begin or end)//   is Resolved(t)          true if there is a resolved time//                                     at or after time t//boolean timeContainerHasEnded(){TimeInstant now = getCurrentTime(); // normalized for time containerboolean assumedResult;// For first or ID, we assume a false result unless we find a child that has ended// For last and all, we assume a true result unless we find a disqualifying childif( ( endsyncRule == first ) || ( endsyncRule == ID ) )   assumedResult = false;else   assumedResult = true;// Our interpretation of endsync == all://          we're done when all children have begun, and none is active//// loop on each child in collection of timed children,//  and consider it in terms of the endsyncRule foreach ( child c in timed-children-collection ){   switch( endsyncRule ) {      case first:         // as soon as we find an ended child, return true.         if( c.hasStarted() & !c.isActive() )            return true;         // else, keep looking (assumedResult is false)         break;      case ID:         // if we find the matching child, just return result         if( endsyncID == c.ID )                 return( c.hasStarted() & !c.isActive() );         // else, keep looking (we'll assume the ID is valid)         break;      case last:         // we just test for disqualifying children         // If the child is active, we're definitely not done.         // If the child has not yet begun but has a resolved begin,         // then we're not done.         if( c.isActive()             || c.begin.isResolved(now) )             return false;         // else, keep checking (the assumed result is true)         break;      case all:         // we just test for disqualifying children        // all_means_last_done_after_all_begin         // If the child is active, we're definitely not done.         // If the child has not yet begun then we're not done.          // Note that if it has already begun,         // then we still have to wait for any more resolved begins         if( c.isActive() || !c.hasStarted()             || c.begin.isResolved(now) )             return false;         // else, keep checking (the assumed result is true)         break;   } // close switch} // close foreach loopreturn assumedResult;} // close timeContainerHasEnded()

The repeatCount,repeatDur, andrepeat attributes: repeating elements

This section is informative

SMIL 1.0 introduced the repeat attribute, which is used to repeat a mediaelement or an entire time container. SMIL 2.0 introduces two new controls forrepeat functionality that supersede the SMIL 1.0repeat attribute. The new attributes,repeatCount andrepeatDur, provide a semantic that moreclosely matches typical use-cases, and the new attributes provide morecontrol over the duration of the repeating behavior.

Repeating an element causes the simple duration to be "played" severaltimes in sequence. This will effectively copy orloop the contentsof the element media (or an entire timeline in the case of a time container).The author may specify eitherhow many timesto repeat, usingrepeatCount, orhow longtorepeat, usingrepeatDur. Eachrepeatiteration is one instance of "playing" the simpleduration.

repeatCount

Specifies the number of iterations of the simple duration. It may have the following attribute values:

numeric value: This is a (base 10) "floating point" numeric value that specifies the number of iterations. It may include partial iterations expressed as fraction values. A fractional value describes a portion of the simple duration. Values must be greater than 0.
"indefinite": The element is defined to repeat indefinitely (subject to the constraints of the parent time container).

repeatDur

Specifies the total duration for repeat. It may have the following attribute values:

Clock-value: Specifies the duration in element active time to repeat the simple duration.
"indefinite": The element is defined to repeat indefinitely (subject to the constraints of the parent time container).

The SMIL 1.0 repeat attribute is deprecated since SMIL 2.0 (it must be supported in SMIL document user agents for backwards compatibility).

This section is informative

See theComputing the Active Duration section for how repeat attributes interact with other timing attributes.

Examples

This section is informative

In the following example, the implicit duration of the audio isconstrained byrepeatCount. Onlythe first half of the clip will play; the active duration will be 1.5seconds.

<audio src="3second_sound.au"repeatCount="0.5" />

In this example, the 3 second (implicit) simple duration will be playedthree times through and then is constrained by thedur attribute on the parentpar; the active duration will be 9 seconds.

<par dur="9s">   <audio src="3second_sound.au" repeatCount="100" /></par>

In the following example, the 2.5 second simple duration will be repeatedtwice; 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 berepeated two full times and then the first half is repeated once more; theactive 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 arepeatCount of 2.8.

<audio src="music.mp3" dur="2.5s"repeatDur="7s" />

Note that if the simple duration is indefinite, repeat behavior is notdefined (butrepeatDur stillcontributes to the active duration). In the following example the simpleduration is 0 and indefinite respectively, and so therepeatCount is ignored. Nevertheless,this is not considered an error. The active duration is equal to the simpleduration: for the first element, the active duration is 0, and for the secondelement, 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 for the image andindefinite for the text element, and so repeat behavior is not meaningful.The active duration is 0 for the first element, however for the secondelement, the active duration is determined by therepeatDur value, and so is 10 seconds.The effect is that the text is shown for 10 seconds.

<img src="foo.jpg"repeatDur="10s" /><text src="intro.html" dur="indefinite"repeatDur="10s" />

In the following example, if the audio media is longer than the 5 secondrepeatDur, then the activeduration will effectively cut short the simple duration.

<audio src="8second_sound.au"repeatDur="5s" />

TherepeatCount andrepeatDur attributes may also be used torepeat an entire timeline (i.e. a time container simple duration), as in thefollowing example. The sequence has an implicit simple duration of 13seconds. It will begin to play after 5 seconds, and then will repeat thesequence of three images 3 times. The active duration is thus 39 secondslong.

<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 minattribute and restart:

This section is informative

Themin attribute does not prevent anelement from restarting before the minimum active duration is reached. If inthe following example, the "user.activateEvent" occurs once at 2 seconds,then again at 5 seconds, the "image" element will begin at 2 seconds, playfor 3 seconds, and then be restarted at 5 seconds. The restarted interval(beginning at 5 seconds) will display the image until 12 seconds.

<smil ...>...<par>   <img xml:id="image" begin="user.activateEvent" min="7s" dur="5s"         restart="always" fill="freeze".../></par>...</smil>

SMIL 1.0 repeat (deprecated)

This section is informative

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 thespecified number ofcopiesof the element without the repeatattribute. This definition has caused some confusion among authors andimplementers. See also the SMIL 1.0 specification[SMIL10].

In particular, there has been confusion concerning the behavior of theSMIL 1.0end attribute when used inconjunction with therepeatattribute. SMIL 3.0 complies with the common practice of having theend attribute define the element's simpleduration when the deprecatedrepeatattribute is used. Only SMIL document user agents must support this semanticfor theend attribute. Only a singleSMIL 1.0 "end" value (i.e. anOffset-value or aSMIL-1-syncbase-value, butnone of the new SMIL 2.0 timing) is permitted when used with the deprecatedrepeat attribute. Ifrepeat is used withrepeatCount orrepeatDur on an element, or ifrepeat is used with an illegalend value, therepeat value is ignored.

repeat: This attribute has been deprecated in SMIL 2.0 in favor of the new repeatCount and repeatDur attributes.; This causes the element to play repeatedly for the specified number of times. It is equivalent to aseq 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.; Legal values areinteger iterations, greater than 0,and"indefinite".

The fillattribute: extending an element

This section is informative

When an element's active duration ends, it may befrozen at the final state, or it may no longer be presented (i.e.,its effect is removed from the presentation).Freezingan elementextends it, using the final state defined in the last instance of the simpleduration. This may be used to fill gaps in a presentation, or to extend anelement as context in the presentation (e.g. with additive animation - seetheSMIL 3.0 Animation chapter).

Thefillattribute allows an author to specify that an element should be extendedbeyond the active duration byfreezing the final state of theelement. Thefill attribute is alsoused to determine the behavior when the active duration is less than theduration specified in themin attribute.For this reason, rather than referring to the end of the active duration,this description refers to the "last instance of the simple duration".

For discrete media, the media is simply displayed as it would be during the simple duration.
For visual continuous media, the "frame" that corresponds to the end of the last instance of the simple duration is shown.
For algorithmic media like animation, the value defined for the end of the last instance of the simple duration should be used.
For time containers, freezing extends the state of all children that are active or frozen at the end of the last instance of the time container simple duration. The children are frozen as they appear at the end of the last instance of the time container simple duration. If a child element ends its active duration coincident to the end of the last instance of its parent time container simple duration, the child elementfill value determines whether the child will be frozen after the end of the parent time container's last simple duration.
A host language integrating Timing must specify the semantics of freezing elements.

The last instance of the simple duration is the last frame or valuethat was played during the last instance (seeThe instance timeslists) of the simple duration of the element before it finished orwas stopped because of an end attribute.

This section is informative

The syntax of the fill attribute is the same as inSMIL 1.0, with two extensions. In addition, the fill attribute may now beapplied to any timed element, including time containers.

This attribute may have the following values:

remove

Specifies that the element will not extend past the end of the last instance of the simple duration.

freeze

Specifies that the element will extend past the end of the last instance of the simple duration by "freezing" the element state at that point. The parent time container of the element determines how long the element is frozen (as described immediately below).

hold

Setting this to"hold" has the same effect as setting to"freeze", except that the element is always frozen to extend to theend of the simple duration of the parent time container of the element (independent of the type of time container). For profiles that support a layered layout model (e.g., SMIL 3.0 Language Profile), held elements (elements withfill="hold") will refresh their display area when a layer is added on top then later removed.

transition

Setting this to"transition" has the same effect as setting to"freeze", except that the element is removed at the end of the transition. This value is only allowed on elements with media directly associated with them. If specified on any other element (e.g. a time container element in the SMIL language profile), the attribute is ignored. See theSMIL Transitions module.

auto

The fill behavior for this element depends on whether the element specifies any of the attributes that define the simple or active duration:

If none of the attributesdur,end,repeatCount orrepeatDur are specified on the element, then the element will have a fill behavior identical to that if it were specified as"freeze".
Otherwise, the element will have a fill behavior identical to that if it were specified as"remove".

default

The fill behavior for the element is determined by the value of thefillDefault attribute.
This is the default value.
If the application offillDefault to an element would result in the element having a value of fill that is not allowed on that element, the element will instead have a fill value of "auto".

This section is informative.

Note that given the default values forfill andfillDefault attributes, if thefill attribute is not specified for anelement, and if thefillDefaultattribute is not specified for any ascendant of the element, the behavioruses"auto" semantics.

An element with"freeze" behavior is extendedaccording to the parent time container:

In apar, the element is frozen to extend to the end of the simple duration of thepar. In this case,fill="freeze" is equivalent tofill="hold".
In aseq, the element is frozen to extend to the begin of the next element in theseq or until the end of the simple duration of theseq. This will fill any gap in the presentation (although it may have no effect if the next element begins immediately).
In anexcl, the element is frozen to extend to the begin of the next element to be activated in theexcl, or until an element in theexcl is resumed, or until the end of the simple duration of theexcl. 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 thefill attribute does not (yet) apply. See alsoexcl element, in the sectionExclSyntax.

When applied to media,fill only hasa presentation effect on visual media. Non-visual media (audio) will simplybe silent (although they are still frozen from a timing perspective).

The fillDefault attribute

Defines the default value for thefill behavior for an element and all descendants.
The values"remove","freeze","hold","transition" and"auto" specify that the element fill behavior is the respective value.

inherit: Specifies that the value of this attribute (and of the fill behavior) are inherited from thefillDefault value of the parent element. If there is no parent element, the value is"auto".
This is the default value.

The Event sensitivity andfill

The effects of thefill attribute apply only to the timingsemantics. If an element is still visible while frozen, it behaves normallywith respect to other semantics such as user event processing. In particular,elements such asa andarea are still sensitive to user activation(e.g. clicks) when frozen. See also the SMIL 1.0 specification[SMIL10].

This section is informative

Thefill attribute may be used tomaintain the value of a media element after the active duration of theelement 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 theaudio element ends. The attribute "freezes" the last value of the element forthe remainder of the time container's simple duration.

This functionality is also useful to keep prior elements on the screenwhile the next item of aseq timecontainer prepares to display as in this example:

<seq>   <video xml:id="v1" fill="freeze" src.../>   <video xml:id="v2" begin="2s" src.../></seq>

The first video is displayed and then the last frame is frozen for 2seconds, until the next element begins. Note that if it takes additional timeto download or buffer video "v2" for playback, the first video "v1" willremain frozen until video "v2" actually begins.

The restart attribute

This section is informative

Note that there are several ways that an element may be restarted. Thebehavior (i.e. to restart or not) in all cases is controlled by therestart attribute. The different restartcases are:

An element withbegin specified as an Event-value may be restarted when the named event fires multiple times.
An element withbegin specified as a syncbase value, where the syncbase element may 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 ofrestart on these elements).
An element withbegin specified as a Begin-value-list.
An element may be restarted when the DOM "beginElement()" method is called repeatedly.

As with any begin time, if an element is scheduled to restart after theend of the parent time container simple duration, the element will notrestart.

For the precise definition of when restart semantics apply, see thesectionEvaluation ofbegin and end time lists.

restart =("always" | "whenNotActive" | "never" | "default" )

always: The element may be restarted at any time.
whenNotActive: The element may only be restarted when it is not active (i.e. itmay be restarted after the active end). Attempts to restart the element during its active duration are ignored.
never: The element cannot be restarted for the remainder of the current simple duration of the parent time container.
default: The restart behavior for the element is determined by the value of therestartDefault attribute.
This is the default value.

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 (including anyfill behavior), and only the new current interval of the element is reflected in the presentation. It should be obvious that this definition applies only to the behavior of the element content, and not to the evaluation of the begin and end times lists described inEvaluation of begin and end time lists.
When an active element restarts, the element first ends the active duration, propagates this to time dependents and raises an endEvent in the normal manner (see alsoEvaluation of begin and end time lists). Restart semantics are evaluatedafter the active duration for an element is computed, and so ending the active duration due to a restart is not subject to the semantics ofmin. See alsoComputing the active duration.
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 alsoControlling runtime synchronization behavior.
Note that if the parent time container (or any ascendant time container) repeats or restarts, any state associated withrestart="never" will be reset, and the element may begin again normally. See alsoResetting element state.

TherestartDefaultattribute may be used to control the default behavior of therestart attribute. This is described belowinControlling the default behaviorof restart.

This section is informative.

For details on when and how therestartattribute is evaluated, seeEvaluation of begin and end timelists.

Using restart for toggle activation

This section is informative

A common use-case requires that the same UI event is used to begin anelement and to end the active duration of the element. This is sometimesdescribed as "toggle" activation, because the UI event toggles the element"on" and "off". Therestartattribute can be used to author this, as follows:

<smil ...>...<img xml:id="foo"begin="bar.activateEvent"end="bar.activateEvent"restart="whenNotActive" .../></smil>

If "foo" were defined with the default restart behavior"always", a second activateEvent on the "bar" elementwould simply restart the element. However, since the second activateEventcannot restart the element whenrestart is set to"whenNotActive", the element ignores the "begin"specification of the activateEvent event. The element may then use theactivateEvent event to end the active duration and stop the element.

Note that in SMIL Language documents, a SMIL element cannot be visiblebefore it begins so having abegin="activateEvent" means it won't ever begin. In languageswithtimeAction support, this may not be the case. For example,the following is reasonable:

<html xmlns:smil="http://www.w3.org/ns/SMIL" ...>...<span smil:begin="click" smil:end="click" smil:timeAction="class:highlight" smil:restart="whenNotActive">  Click here to highlight. Click again to remove highlight.</span>...</html>

This is based upon the event sensitivity semantics described in Event sensitivity andUnifying Scheduling and InteractiveTiming.

Controlling the default behavior ofrestart

The following attribute is provided to specify thedefault behavior forrestart:

restartDefault =( "always" | "whenNotActive" | "never" | "inherit" )

Defines the behavior of therestart attribute when its value is"default".
The values"always","whenNotActive" and"never" specify that the element restart behavior is the respective value.

inherit: Specifies that the value of this attribute (and of the restart behavior) are inherited from the restartDefault value of the parent element. If there is no parent element, the value is"always".
This is the default value.

This section is informative.

Given the default values of this attribute("inherit")and of therestartattribute("default"), a document that does not specify these attributes will haverestart="always" behavior for all timed elements.

Resetting element state

When a time container repeats or restarts, all descendant children are"reset" with respect to certain state:

Any instance times associated with past Event-values, Repeat-values, Accesskey-values or added via DOM method calls are removed from the dependent begin and end instance times lists. In effect, all events and DOM methods calls in the past are cleared. This does not apply to an instance time that defines the begin of the current interval. (See alsoEvaluation of begin and end time lists)
Any syncbase times are reevaluated (i.e. the translation between timespaces must be recalculated - seeConverting between local and global times).
A resolved syncbase time is removed from the dependent instance time list when a common ascendant of the syncbaseand the dependent element restarts or repeats
Any state associated with the interpretation of therestart semantics is reset.

This section is informative

Thus, for example if an element specifiesrestart="never", the element may begin again after a reset. Therestart="never" setting is only defined for the extent of theparent time container simple duration.

When an element restarts, rules 1 and 2 are also applied to the elementitself, although rule 4 (controlling restart behavior) is not applied.

Note that when any time container ends its simple duration (including whenit repeats), all timed children that are still active are ended. See alsoTime containerconstraints on child durations.

When anexcl time container restartsor repeats, in addition to ending any active children, the pause queue fortheexcl is cleared.

The syncBehavior,syncTolerance, andsyncMaster attributes: controllingruntime synchronization

This section is informative

New support in SMIL 2.0 introduces finer grained control over the runtimesynchronization behavior of a document. ThesyncBehavior attribute allows anauthor to describe for each element whether it must remain in a hard syncrelationship to the parent time container, or whether it may be allowed slipwith respect to the time container. Thus, if network congestion delays orinterrupts the delivery of media for an element, thesyncBehavior attribute controlswhether the media element may slip while the rest of the document continuesto play, or whether the time container must also wait until the mediadelivery catches up.

ThesyncBehavior attributemay also be applied to time containers. This controls the sync relationshipof the entire timeline defined by the time container. In this example, theaudio and video elements are defined with hard or "locked" sync to maintainlip sync, but the "speech"par timecontainer is allowed to slip:

<par>   <animation src="..." />   ...   <par xml:id="speech" syncBehavior="canSlip" >      <video src="speech.mpg" syncBehavior="locked" />      <audio src="speech.au"  syncBehavior="locked" />   </par>   ...</par>

If either the video or audio must pause due to delivery problems, theentire "speech" par will pause, to keep the entire timeline in sync. However,the rest of the document, including the animation element will continue toplay normally. Using thesyncBehavior attribute on elementsand time containers, the author can effectively describe the "scope" ofruntime sync behavior, defining some portions of the document to play in hardsync without requiring that the entire document use hard synchronization.

This functionality also applies when an element first begins, and themedia must begin to play. If the media is not yet ready (e.g. if an imagefile has not yet downloaded), thesyncBehavior attribute controlswhether the time container must wait until the element media is ready, orwhether the element begin may slip until the media is downloaded.

An additional extension allows the author to specify that a particularelement should define or control the synchronization for a time container.This is similar to the default behavior of many user agents that "slave"video and other elements to audio, to accommodate the audio hardwareinaccuracies and the sensitivity of listeners to interruptions in the audioplayback. ThesyncMasterattribute allows an author to explicitly define that an element defines theplayback "clock" for the time container, and all other elements should beheld in sync relative to thesyncMaster element.

In practice,linear media often need tobe the syncMaster, wherenon-linear mediacan more easily be adjusted to maintain hard sync. However, a user agentcannot always determine which media behaves in a linear fashion and whichmedia behaves in a non-linear fashion. In addition, when there are multiplelinear elements active at a given point in time, the user agent cannot alwaysmake the "right" decision to resolve sync conflicts. ThesyncMaster attribute allows the authorto specify the element that has linear media, or that is "most important" andshould not be compromised by thesyncBehavior of other elements.

syncBehavior = ("canSlip" | "locked" | "independent" | "default" )

Defines the runtime synchronization behavior for an element.
Legal values are:

canSlip: Allows the associated element to slip with respect to the parent time container.
When this value is used, any syncTolerance attribute is ignored.
locked: Forces the associated element to maintain sync with respect to the parent time container. This may be eased with the use of the syncTolerance attribute.
independent: Declares an independent timeline that is scheduled with the timegraph, but will ignore any seek operations on the parent.
default: The runtime synchronization behavior for the element is determined by the value of thesyncBehaviorDefault attribute.
This is the default value.

The argument valueindependent is equivalent to settingsyncBehavior="canSlip" andsyncMaster="true" so that the element is scheduled within the timegraph, but is unaffected by any other runtime synchronization issues. SettingsyncBehavior="canSlip" andsyncMaster="true" declares the element as being the synchronization master clock and that the element may slip against its parent time line

syncTolerance = (Clock-value | "default" )

This attribute on timed elements and time containers defines the synchronization tolerance for the associated element . The attribute has an effect only if the element's runtime synchronization behavior is"locked". This allows a locked sync relationship to ignore a given amount of slew without forcing resynchronization.

Clock-value: Specifies the synchronization tolerance as a value. Clock values are measured in element simple time.
default: The synchronization tolerance for the element is determined by the value of thesyncToleranceDefault attribute.
This is the default value.

syncMaster = ("true" |"false" ): Boolean attribute on media elements and time containers that forces other elements in the time container to synchronize their playback to this element.
The default value isfalse.

ThesyncBehavior may affect the effective begin and effective end of an element, but the use of thesyncBehavior attribute does not introduce any other semantics with respect to duration.
When thesyncBehavior attribute is combined with interactive begin timing or restarting an element, the syncBehavior only applies once the sync relationship of the element is resolved (e.g. when the specified event is raised). If at that point the media is not ready andsyncBehavior is specified as"locked", then the parent time container must wait until the media is ready. Once an element with an interactive begin time has begun playing, the syncBehavior semantics described above apply as though the element were defined with scheduled timing.
ThesyncBehavior attribute is subordinate to any sync relationships defined by time containers, sync arcs, event arcs, restart behavior, etc. ThesyncBehavior attribute has no bearing on the formation of the time graph, only the enforcement of it.
ThesyncMaster attribute interacts with thesyncBehaviorattribute. An element withsyncMaster set to true will define sync for the "scope" of the time container's synchronization behavior. That is, if thesyncMaster element's parent time container hassyncBehavior="locked", thesyncMaster will also define sync for the ancestor timeContainer. ThesyncMaster will define sync for everything within the closest ancestor time container that is defined withsyncBehavior="canSlip".
ThesyncMaster attribute only applies when an element is active and not paused. If more than one element within thesyncBehavior scope has thesyncMaster attribute set to"true", and the elements are both active and not paused at any moment in time, the sync master element is the first of these elements encountered in a post order traversal of the document tree as defined by DOM[DOM2]. In this conflict case, the other elements effectively ignore thesyncMaster attribute.
When an element is paused, the semantics of thesyncMaster attribute are effectively ignored. Nevertheless, any accumulated synchronization offset associated withsyncMaster semantics (that is an offset accumulated while the sync master element was not paused) is not changed when the sync master element pauses. The offset in this case will be the offset for the closest ancestor time container that is defined withsyncBehavior="canSlip". See alsoThe accumulated synchronization offset.

This section is informative

Note that the semantics of syncBehavior do not describe or require aparticular approach to maintaining sync; the approach will be implementationdependent. Possible means of resolving a sync conflict may include:

Pausing the parent time container (i.e. first ancestor time container withcanSlip behavior) until the element that slipped can "catch up".
Pausing the element that is playing too fast until the parent (document) time container catches up.
Seeking (i.e. resetting the current position of) the element that slipped, jumping it ahead so that it "catches up" with the parent time container. This would only apply to non-linear media types.

Additional control is provided over the hard sync model using thesyncToleranceattribute. This specifies the amount of slip that may be ignored foran element. Small variance in media playback (e.g. due to hardwareinaccuracies) can often be ignored, to allow the overall performanceto appear smoother.

When any element is paused (including the cases described above forruntime sync behavior), the computed end time for the element may change oreven become resolved, and the time model must reflect this. This is detailedinPaused elements and theactive duration.

Controlling the default behavior

Two attributes are defined to specify the defaultbehavior for runtime synchronization:

syncBehaviorDefault = ("canSlip" | "locked" | "independent" | "inherit" )

Defines the behavior of thesyncBehavior attribute when its value is"default".
The values"canSlip","locked" and"independent" specify that the element's runtime synchronization behavior is the respective value.

inherit: Specifies that the value of this attribute (and the value of the element's runtime synchronization behavior) are inherited from thesyncBehaviorDefault value of the parent element. If there is no parent element, the value is implementation dependent.
This is the default value.

syncToleranceDefault = (Clock-value | "inherit" )

Defines the behavior of thesyncTolerance attribute when its value is"default".
Clock values specify that the element's runtime synchronization tolerance value is the respective value.

inherit: Specifies that the value of this attribute (and the value of the element's runtime synchronization tolerance value) are inherited from thesyncToleranceDefault value of the parent element. If there is no parent element, the value is implementation dependent but should be no greater than two seconds.
This is the default value.

The accumulated synchronization offset

If an element slips synchronization relative to its parent, the amount ofthis slip at any point is described as theaccumulated synchronizationoffset. This offset is used to account for pause semantics as well asperformance or delivery related slip. This value is used to adjust theconversion between element and parent times, as described inConverting between local and globaltimes. The offset is computed as follows:

Lett_c(t_ps) be the computed element active time for an element at the parent simple timet_ps, according to the defined synchronization relationship for the element.
Lett_o(t_ps) be the observed element active time for an element at the parent simple timet_ps.
The accumulated synchronization offsetO is:
O = t_o(t_ps) - t_c(t_ps)
This offset is measured in parent simple time.

This section is informative.

Thus an accumulated synchronization offset of 1 second corresponds to theelement playing 1 second "later" than it was scheduled. An offset of -0.5seconds corresponds to the element playing a half second "ahead" of where itshould be.

Attributes for timing integration:timeContainer and timeAction

This section is informative

The modularization of SMIL 3.0 functionality allows language designers tointegrate SMIL Timing and Synchronization support into any XML language. Inaddition to just scheduling media elements as in SMIL language documents,timing may be applied to the elements of the host language. For example, theaddition of timing to HTML (i.e. XHTML) elements will control thepresentation of the HTML document over time, and to synchronize text andpresentation with continuous media such as audio and video.

Two attributes are introduced to support these integration cases. ThetimeContainer attribute allowsthe author to specify that any XML language element has time containerbehavior. E.g., an HTML<ol> ordered list element may bedefined to behave as a sequence time container. ThetimeAction attribute allows the authorto specify what it means to apply timing to a given element.

The timeContainer attribute

XML language elements may be declared to have time container semantics byadding thetimeContainerattribute. The syntax is:

timeContainer =( "par" | "seq" | "excl" | "none" )

par: Defines a parallel time container.
seq: Defines a sequence time container.
excl: Defines an exclusive time container.
none: Defines the current element tonot have time container behavior (i.e. to behave as a simple time leaf).
This is the default.

Constraints upon the use of thetimeContainer attribute are:

Language designers may restrict the set of elements that may be time containers, but any element may in principle be a time container.
An element with thetimeContainer attribute behaves the same as a media time container. If the element has no intrinsic media duration, then the element may behave the same as the respective time container element. Language designers must specify which elements have intrinsic media duration, and how this is defined.
ThetimeContainer attributemay notbe applied to any of the SMIL time container elementspar,seq orexcl.
ThetimeContainer attributemaybe applied to SMIL media elements (with timed children) to control the behavior of a media time container.

The timeAction attribute

ThetimeAction attributeprovides control over the effect of timing upon an attribute. A host languagemust specify which values are allowed for each element in the language. Ahost language must specify the intrinsic timing behavior of eachelement to whichtimeAction maybe applied. In addition, a host language may specify additionaltimeAction values. The syntax is:

intrinsic: Specifies that timing controls the intrinsic behavior of the element.
This is the default.
display: Specifies that timing controls the display of the element, as defined by CSS. The timing of the element may affect the presentation layout. For languages that incorporate CSS, the CSS "display" property should be controlled over time.
visibility: Specifies that timing controls the visibility of the element, as defined by CSS. The timing of the element should not affect the presentation layout. For languages that incorporate CSS, the CSS "visibility" property should be controlled over time.
style: Specifies that timing controls the application of style defined by an inline "style" attribute.
class:classname: Specifies that timing controls the inclusion of the specifiedclass-name in the set of classes associated with the element (i.e. the XMLclass attribute value list).
none: Specifies that timing has no effect upon the presentation of the element.

Theintrinsic behavior is defined by a hostlanguage. For example in the SMIL language, theintrinsic behavior of media elements is to schedule andcontrol the visibility of the media. For some elements or some languages, theintrinsic behavior may default to one of theother behaviors.

AdditionaltimeActionsemantics and constraints:

SMIL media elements define theintrinsic behavior as the scheduling and playback of the media. WhentimeAction is set to any other value (besidesintrinsic), theintrinsic scheduling behavior will be controlledin addition to the specifiedtimeAction.
SMIL time container elements (par,seq, andexcl) define theintrinsic behavior as simply performing the scheduling semantics. When theintrinsic behavior is specified, only the scheduling semantics are controlled. Timing does not otherwise control the presentation styling of the element. WhentimeAction is set to any other value (besidesintrinsic), theintrinsic scheduling behavior will be controlledin addition to the specifiedtimeAction.
It is recommended that phrasal, presentation, and style-like elements (e.g., XHTML'sb,em,strong, ...etc.) have anintrinsic behavior that applies the associated semantic (e.g. toembolden oremphasize the content of the element). WhentimeAction is set to any other value (besidesintrinsic), theintrinsic behavior will be controlledin addition to the specifiedtimeAction.
It is recommended that "content" elements (e.g., XHTML'sp,div,span) have an intrinsic behavior equivalent tovisibility. WhentimeAction is set to any other value (besidesintrinsic), theintrinsic behavior shouldnotbe controlled, but rather only the specifiedtimeAction should be applied.
If a language supports CSS styling, the presentation effect ofdisplay andvisibility should use the CSS override style, rather than setting the original value for the associated properties. This model for presentation values is described in theSMIL 3.0 Animation module.
If a language supports CSS styling, thevisibility property should be set to "hidden" when the element is not active or frozen. If the original value of thevisibility property was not "hidden", the original value should be used when the element is active or frozen. If the original value of thevisibility property was "hidden", the property should be set to "visible" when the element is active or frozen.
If a language does not support CSS styling, the presentation semantics ofdisplay andvisibility must be specified, or the attribute values must be disallowed.
If a language does not support a "style" attribute, thestyle value fortimeAction should not be allowed.
When theclass argument value is specified, the specified class name should beadded tothe class list of the element when the element is active or frozen. Other values in the class list must be preserved. If the specified class name is specified in the class list (i.e. if it is specified in theclass attribute), the class name should be removed from the class list of the element when the element is not active or frozen.
When thenone argument value is specified, no action is controlled by the timing, except any intrinsic behavior. This value is generally only useful on an element that also specifies atimeContainer value. In this case, the time containment semantic applies, but no presentation effect is applied to the element.

Certain special elements may have specificintrinsic semantics. For example, linking elements likea andarea may have anintrinsic behavior that controls the sensitivity of theelements to actuation by the user. This may have presentation side-effects aswell. In XHTML for example, making these elements insensitive also has theeffect that the default styling (e.g. a color and underline) that is appliedto sensitive links is removed when the element is not active or frozen.

Host language designers should carefully consider and define the behaviorassociated with applying timing to an element. For example,script elements could be defined to execute when the elementbegins, or the language could disallow thetimeAction attribute on the element.Similarly,linkelements could apply a linked stylesheet whenthe element begins or the language could disallow thetimeAction attribute onlink.

For details of the CSS propertiesvisibility anddisplay, see[CSS2].

Examples:

This section is informative.

These examples assume that the namespace declarationxmlns:smil="http://www.w3.org/ns/SMIL" is in scope.

The following example shows a simple case of controlling visibility overtime. The text is hidden from 0 to 3 seconds, shown normally for 5 seconds,and then hidden again.

<span smil:timeAction="visibility" smil:begin="3s" smil:dur="5s">   Show this text for a short period.</span>

The following example shows a simple case of controlling display overtime. Each list element is shown for 5 seconds, and is removed from thelayout when not active or frozen. The ordered list element is set to be asequence time container as well (note that each list element retains itsordinal number even though the others are not displayed):

<ol smil:timeContainer="seq" smil:repeatDur="indefinite">   <li smil:timeAction="display" smil:dur="5s">      This is the first thing you will see. </li>   <li smil:timeAction="display" smil:dur="5s">      You will see this second. </li>   <li smil:timeAction="display" smil:dur="5s">      Last but not least, you will see this. </li></ol>

The following example shows how an element specific style may be appliedover time. The respective style is applied to each HTMLlabelfor 5 seconds after a focus event is raised on the element:

<form ...>...   <label for="select_red"smil:begin="focus" smil:dur="5s" smil:timeAction="style"          >      Make things RED.   </label>   <input xml:id="select_red" .../>   <label for="select_green"smil:begin="focus" smil:dur="5s" smil:timeAction="style"          >      Make things GREEN.   </label>   <input xml:id="select_green" .../>...</form>

5.4.4 Elements

This section is informative

SMIL 3.0 specifies three types of time containers. These may be declaredwith the elementspar,seq, andexcl, or in some integration profiles with atimeContainer attribute. Mediaelements with timed children are defined to be "media time containers", andhave semantics based upon theparsemantics (see alsoAttributes fortiming integration: timeContainer and timeAction andImplicit duration ofmedia element time containers).

This document refers in general to time containers by reference to theelements, but the same semantics apply when declared with an attribute, andfor media time containers.

The parelement

par: Apar container, short for "parallel", defines a simple time grouping in which multiple elements may play back at the same time.

The implicit syncbase of the child elements of apar is the begin of thepar. The default value ofbegin for children of apar is"0".

This section is informative.

This is the same element introduced with SMIL 1.0.

Thepar elementsupports all element timing.

Implicit duration ofpar

The implicit duration of apar is controlled byendsync. By default, the implicit durationof apar is defined by theendsync="last"semantics. The implicit duration ends with the last active end of the childelements.

The seqelement

seq: Aseq container defines a sequence of elements in which elements play one after the other.

This section is informative.

This is the same element introduced with SMIL 1.0, butthe semantics (and allowed syntax) for child elements of aseq are clarified.

The implicit syncbase of the child elements of aseq is the active end of thepreviouselement.Previous means the element that occurs before this element in the sequence time container. For the first child of a sequence (i.e. where no previous sibling exists), the implicit syncbase is the begin of the sequence time container.
For children of a sequence, the only legal value for begin is a (single) non-negative offset value.
The default begin value is "0". None of the following begin values may be used:
disallowed begin-values:
(syncbase-value | event-value | media-marker-value | wallclock-sync-value | repeat-value | accesskey-value | "indefinite")
Note however that child elementsmay define anend that references other syncbases, event-bases, etc.

Theseq element itself supports allelement timing exceptendsync.

When a hyperlink traversal targets a child of aseq, and the target child is not currentlyactive, part of the seek action must be to enforce the basic semantic of aseq that only one child may be active ata given time. For details, seeHyperlinks and timing and specificallyImplications ofbeginElement() and hyperlinking forseq andexcl time containers.

Implicit duration ofseq containers

The implicit duration of aseq ends with the active end of the last child of theseq.
If any child of aseq has an indefinite active duration, the implicit duration of theseq is also indefinite.

The exclelement

This section is informative.

SMIL 3.0 defines a time container,excl, that allows the interactive (ora-temporal) activation of child elements.

excl: This defines a time container with semantics based uponpar, but with the additional constraint that only one child element may play at any given time. If any element begins playing while another is already playing, the element that was playing is stopped. If thepriorityClass element is also supported by a profile, child elements in anexcl container may be grouped into categories; the behavior of the element that was playing at the time a new element starts may be defined to have stop/pause/interruption behavior. ThepriorityClass may be used to define several levels of interrupt behavior (one per class), each of which may be controlled explicitly.

The implicit syncbase of the child elements of theexcl is thebegin of theexcl. The default value ofbegin for children ofexcl is"indefinite". This means that theexcl has 0 duration unless a child of theexcl has been added to thetimegraph.

Theexcl element itself supports allelement timing.

This section is informative

With theexcl time container, commonuse cases that were either difficult, or impossible, to author are now easierand possible to create. Theexcl timecontainer is used to define a mutually exclusive set of clips, and todescribe pausing and resuming behaviors among these clips. Examplesinclude:

interactive playlist: A selection of media clips is available for the user to choose from, only one of which plays at a time. A new selection replaces the current selection.
audio descriptions: For visually impaired users, the current video is paused and audio descriptions of the current scene are played. The video resumes when the audio description completes.
interactive video sub-titles: Multiple language sub-titles are available for a video. Only one language version may be shown at a time with the most recent selection replacing the previous language choice, if any.

The interactive playlist use case above could be accomplished using apar whose sources have interactive begintimes andend events for all othersources. This would require a prohibitively long list of values forend to maintain. Theexcl time container provides a convenientshort hand for this - the element begin times are still interactive, but theend events do not need to be specifiedbecause theexcl, by definition, onlyallows one child element to play at a time.

The audio descriptions use case is not possible without the pause/resumebehavior provided byexcl andpriorityClass. This use case wouldbe authored with a video and each audio description as children of theexcl. The video element would be scheduled tobegin when theexcl begins and theaudio descriptions, peers of the video element, would start at scheduledbegin times or in response to stream events raised at specific times.

The dynamic video sub-titles use case requires the "play only one at atime" behavior ofexcl. In addition,the child elements are declared in such a way so as to preserve the syncrelationship to the video:

<smil ...>...<par endsync="vid1">   <video xml:id="vid1" .../>   <excl dur="indefinite">      <par begin="englishBtn.activateEvent" >         <audio begin="vid1.begin" src="english.au" />      </par>      <par begin="frenchBtn.activateEvent" >         <audio begin="vid1.begin" src="french.au" />      </par>      <par begin="swahiliBtn.activateEvent" >         <audio begin="vid1.begin" src="swahili.au" />      </par>   </excl></par>...</smil>

The threepar elements are childrenof theexcl, and so only one can playat a time. The audio child in eachparis defined to begin when the video begins. Each audio can only be active whenthe parent time container (par) isactive, but the begin still specifies the synchronization relationship. Thismeans that when eachpar begins, theaudio will start playing at some point in the middle of the audio clip, andin sync with the video.

Theexcl time container is useful inmany authoring scenarios by providing a declarative means of describingcomplex clip interactions.

Implicit duration ofexcl containers

The implicit duration of anexcl container is defined the same as for apar container, using theendsync="last" semantics. However, since the default timing for children ofexcl is interactive, the implicit duration forexcl time containers with only default timing on the children will be 0.

The priorityClass element

This section is informative

Using priority classes to control the pausing behavior of children of theexcl allows the author to group contentinto categories of content, and then to describe rules for how each categorywill interrupt or be interrupted by other categories. Attributes of the newgrouping elementpriorityClassdescribe the intended interactions.

EachpriorityClass elementdescribes a group of children, and the behavior of those children wheninterrupted by other time-children of theexcl. The behavior is described in terms ofpeers, andhigher andlower priority elements.Peers are those elements within the samepriorityClass element.

When one element within theexclbegins (or would normally begin) while another is already active, severalbehaviors may result. The active element may be paused or stopped, or theinterrupting element may be deferred, or simply blocked from beginning.

The careful choice of defaults makes common use cases very simple. See theexamples below.

priorityClass: Defines a group ofexcl time-children, and the pause/interrupt behavior of the children. If apriorityClass element appears as the child of anexcl, then theexcl must only containpriorityClass elements (i.e. the author must not mix timed children andpriorityClass elements within anexcl).

If nopriorityClass element is used, all the children of theexcl are considered to bepeers,with the defaultpeers behavior"stop".

priorityClass elements may only appear as immediate children ofexcl elements and cannot be nested.
Only elements allowed as immediate children of excl may appear as immediate children ofpriorityClass elements.
ThepriorityClass element is transparent to timing, and does not participate in or otherwise affect the normal timing behavior of its children (i.e. it only defines how elements interrupt one another).
Child elements of thepriorityClass elements are time-children of theexcl element (i.e. the parentexcl of thepriorityClass elements).
ThepriorityClass elements are assigned priority levels based upon the order in which they are declared within theexcl. The firstpriorityClass element has highest priority, and the last has lowest priority.
When elements are paused or deferred, they are added to a queue of pending elements. When an active element completes its active duration, the first element (if any) in the queue of pending elements is made active. The queue is ordered according to rules describedin Pause queue semantics.

Thepeers,higher, andlower attributes

This section is informative

Note that the rules define the behavior of thecurrently active element and the interrupting element. Any elements in thepause queue are not affected (except that their position in the queue may bealtered by new queue insertions).

peers =( "stop" | "pause" | "defer" | "never" )

Controls how child elements of thispriorityClass will interrupt one another.
Legal values for the attribute are:

stop: If a child element begins while another child element is active, the active element is simply stopped.
This is the default forpeers.
pause: If a child element begins while another child element is active, the active element is paused and will resume when the new (interrupting) element completes its active duration (subject to the constraints of theexcl time container). The paused element is added to the pause queue.
defer: If a child element attempts to (i.e. would normally) begin while another child element is active, the new (interrupting) element is deferred until the active element completes its active duration.
never: If a child element attempts to (i.e. would normally) begin while another child element is active, the new (interrupting) element is prevented from beginning. The begin of the new (interrupting) element is ignored.

higher =( "stop" | "pause" )

Controls how elements with higher priority will interrupt child elements of thispriorityClass.
Legal values for the attribute are:

stop: If a higher priority element begins while a child element of thispriorityClass is active, the active child element is simply stopped.
pause: If a higher priority element begins while a child element of thispriorityClass is active, the active child element is paused and will resume when the new (interrupting) element completes its active duration (subject to the constraints of theexcl time container). The paused element is added to the pause queue.
This is the default for thehigher attribute.

lower =( "defer" | "never" )

Controls how elements defined with lower priority will interrupt child elements of thispriorityClass.
Legal values for the attribute are:

defer: If a lower priority element attempts to (would normally) begin while a child element of thispriorityClass is active, the new (interrupting) element is deferred until the active element completes its active duration. The rules for adding the element to the queue are described below.
This is the default for thelower attribute.
never: If a lower priority element attempts to begin while a child element of thispriorityClass is active, the new (interrupting) element is prevented from beginning. The begin of the new (interrupting) element is ignored, and it is not added to the queue.

When an element begin is blocked (ignored) because of the"never" attribute value, the blocked element does notbegin in the time model. The time model should not propagate begin or endactivations to time dependents, nor should it raisebegin orend events.

ThepauseDisplay attribute

This section is informative

ThepauseDisplay attribute controls the behavior when paused of the children of apriorityClass element. When a childof apriorityClass element ispaused according toexcl andpriorityClass semantics, thepauseDisplay attribute controlswhether the paused element will continue toshow orapplythe element (i.e. the state of the element for the time at which it ispaused), or whether it is removed altogether from the presentation (i.e.disabled) while paused.

pauseDisplay =( "disable" | "hide" | "show" )

Controls how child elements of thepriorityClass element behave when paused. This attribute only applies ifpeers="pause" orhigher="pause".
Legal values for the attribute are:


disable: Continue to display visual media when the element is paused by theexcl andpriorityClass, but appear disabled. It is implementation dependent how a disabled element appears (rendered in some different way to distinguish from the active state -- e.g., grayed out); disabled elements do not respond to mouse events.
hide: Remove the effect of the element (including any rendering) when the element is paused by theexcl andpriorityClass semantics.
show: Continue to show the effect of the element (including any rendering) when the element is paused by theexcl andpriorityClass semantics. This value has no effect on a aural media.
This is the default.

Examples usingexcl andpriorityClass

This section is informative

Note that because of the defaults, the simple cases work without anyadditional syntax. In the basic case, all the elements default to be peers,and stop one another:

<excl dur="indefinite">   <audio xml:id="song1" .../>   <audio xml:id="song2" .../>   <audio xml:id="song3" .../>   ...   <audio xml:id="songN" .../></excl>

is equivalent to the following with explicit settings:

<excl dur="indefinite">   <priorityClass peers="stop">     <audio xml:id="song1" .../>     <audio xml:id="song2" .../>     <audio xml:id="song3" .../>     ...     <audio xml:id="songN" .../>   </priorityClass></excl>

If the author wants elements to pause rather than stop, the syntax is:

<excl dur="indefinite">   <priorityClass peers="pause">     <audio xml:id="song1" .../>     <audio xml:id="song2" .../>     <audio xml:id="song3" .../>     ...     <audio xml:id="songN" .../>   </priorityClass></excl>

The audio description use case for visually impaired users would look verysimilar to the previous example:

<excl dur="indefinite">   <priorityClass peers="pause">     <video xml:id="main_video" .../>     <audio xml:id="scene1_description" begin="20s"  dur="30s".../>     <audio xml:id="scene2_description" begin="2min" dur="30s" .../>     ...     <audio xml:id="sceneN_description" .../>   </priorityClass></excl>

This example shows a more complex case of program material and severalcommercial insertions. The program videos will interrupt one another. The adswill pause the program, but will not interrupt one another.

<excl dur="indefinite">   <priorityClass xml:id="ads" peers="defer">     <video xml:id="advert1" .../>     <video xml:id="advert2" .../>   </priorityClass>   <priorityClass xml:id="program" peers="stop" higher="pause">     <video xml:id="program1" .../>     <video xml:id="program2" .../>     <video xml:id="program3" .../>     <video xml:id="program4" .../>   </priorityClass></excl>

The following example illustrates how defer semantics and priority groupscan interact. When "alert1" tries to begin at 5 seconds, the "program"priorityClass will force "alert1" todefer, and so "alert1" will be placed upon the queue. When "alert2" tries tobegin at 6 seconds, the same semantics will force "alert2" onto the queue.Note that although the "alerts"priorityClass defines thepeers rule as "never", "alert1" is notactive at 6 seconds, and so the interrupt semantics between "alert1" and"alert2" are not evaluated. The resulting behavior is that when "prog1" endsat 20 seconds, "alert1" will play, and then when "alert1" ends, "alert2" willplay.

<excl dur="indefinite">   <priorityClass xml:id="program" lower="defer">     <video xml:id="prog1" begin="0" dur="20s" .../>   </priorityClass>   <priorityClass xml:id="alerts" peers="never">     <video xml:id="alert1" begin="5s" .../>     <video xml:id="alert2" begin="6s" .../>   </priorityClass></excl>

This example illustratespauseDisplay control. When an elementis interrupted by a peer, the interrupted element pauses and is shown in adisabled state. It is implementation dependent how the disabled video isrendered. Disabled elements do not respond to mouse events.

<excl dur="indefinite">   <priorityClass peers="pause" pauseDisplay="disable">      <video xml:id="video1" .../>      <video xml:id="video2" .../>      <video xml:id="video3" .../>      ...      <video xml:id="videoN" .../>   </priorityClass></excl>

In this example, when a child of a higherpriorityClass element interrupts achild of the "program"priorityClass, the child of"program" pauses and remains onscreen. If a peer of the "program"priorityClass interrupts a peer, theelement that was playing stops and is no longer displayed.

<excl dur="indefinite">   <priorityClass xml:id="ads" peers="defer">      <video xml:id="advert1" .../>      <video xml:id="advert2" .../>   </priorityClass>   <priorityClass xml:id="program" peers="stop" higher="pause" pauseDisplay="show">      <video xml:id="program1" .../>      <video xml:id="program2" .../>      <video xml:id="program3" .../>      <video xml:id="program4" .../>   </priorityClass></excl>

Pause queue semantics

Elements that are paused or deferred are placed in a priority-sorted queueof waiting elements. When an active element ends its active duration and thequeue is not empty, the first (i.e. highest priority) element in the queue ispulled from the queue and resumed or activated.

The queue semantics are described as a set of invariants and the rules forinsertion and removal of elements. For the purposes of discussion, the childelements of apriorityClasselement are considered to have the priority of thatpriorityClass, and to have thebehavior described by thepeers,higher andlower attributes on thepriorityClass parent.

Queue invariants

The queue is sorted by priority, with higher priority elements before lower priority elements.
An element may not appear in the queue more than once.
An element may not simultaneously be active and in the queue.

Element insertion and removal

Elements are inserted into the queue sorted by priority (by invariant 1).
1. Paused elements are insertedbefore elements with the same priority.
2. Deferred elements are insertedafter elements with the same priority.
Where the semantics define that an active element must be paused, the element is paused at the current simple time (position) when placed on the queue. When a paused element is pulled normally from the queue, it will resume from the point at which it was paused.
Where the semantics define that an element must be deferred, the element is inserted in the queue,but is not begun. When the element is pulled normally from the queue, it will begin (i.e. be activated).
When an element is placed in the queue any previous instance of that element is removed from the queue (by invariant 2).
When the active child (i.e. time-child) of anexcl ends normally (i.e. not when it isstopped by another, interrupting element), the element on the front of the queue is pulled off the queue, and resumed or begun (according to rule 2 or 3).

Note that if an element is active and restarts (subject to therestart rule), it does not interruptitself in the sense of a peer interrupting it. Rather, it simply restarts andthe queue is unaffected.

Runtime synchronization behavior and pause/defer semantics

The runtime synchronization behavior of an element(described in thesyncBehavior,syncTolerance, andsyncMaster attributes: controllingruntime synchronization) does not affect the queue semantics. Any elementthat is paused or deferred according to the queue semantics will behave asdescribed. When a paused element is resumed, the synchronization relationshipwill be reestablished according to the runtime synchronization semantics. Thesynchronization relationship for a deferred element will be established whenthe element actually begins.

Calculated times andpause/defer semantics

When an element is paused, the calculated end time forthe element may change or even become resolved, and the time model mustreflect this. This is detailed inPaused elements and the activeduration. In some cases, the end time is defined by other elementsunaffected by the pause queue semantics.

This section is informative.

In the following example, the "foo" element will be paused at 8 seconds,but it will still end at 10 seconds (while it is paused):

<img "joe" end="10s" .../><excl dur="indefinite">   <priorityClass peers="pause">      <img xml:id="foo" end="joe.end" .../>      <img xml:id="bar" begin="8s" dur="5s" .../>   </priorityClass></excl>

If an element ends while it is in the pause queue, it is simply removedfrom the pause queue. All time dependents will be notified normally, and theend event will be raised at the end time, as usual.

When an element is deferred, the begin time is deferred as well. Just asdescribed inPaused elements andthe active duration, the begin time of a deferred element may becomeunresolved, or it may simply be delayed.

This section is informative.

In the following example, the "bar" element will initially have anunresolved begin time. If the user clicks on "foo" at 8 seconds, "bar" wouldresolve to 8 seconds, but will be deferred until 10 seconds (when "foo"ends):

<smil ...>...<excl dur="indefinite">   <priorityClass peers="defer">      <img xml:id="foo" begin="0s" dur="10s" .../>      <img xml:id="bar" begin="foo.click" .../>   </priorityClass></excl>...</smil>

If there is enough information to determine the newbegin time (as in the example above), an implementation must compute thecorrect begin time when an element is deferred. The change to the begin timethat results from the element being paused must be propagated to any sync arctime dependents (i.e. other elements with a begin or end defined relative tothe begin of the deferred element). See also thePropagating changes to times section.

This section is informative.

One exception to normal processing is made fordeferred elements, to simplify the model: a deferred element ignorespropagated changes to its begin time. This is detailed in theDeferred elements and propagatingchanges to begin section.

Scheduled begin times andexcl

Although the default begin value for children of anexcl is indefinite, scheduled begintimes are permitted. Scheduled begin times on children of theexcl cause the element to begin at thespecified time, pausing or stopping other siblings depending on thepriorityClass settings (and defaultvalues).

Handling SimultaneousBegins withinexcl

If children of anexcl attempt to begin at the same time, theevaluation proceeds in document order. For each element in turn, thepriorityClass semantics are considered, and elements may be paused, deferredor stopped.

This section is informative

The following examples both exhibit this behavior (it can result from anycombination of scheduled times, interactive timing, hyperlink or DOMactivation):

<smil ...>...<excl>   <img src="image1.jpg" begin="0s" dur="5s"/>   <img src="image2.jpg" begin="0s" dur="5s"/>   <img src="image3.jpg" begin="0s" dur="5s"/></excl><excl dur ="indefinite">   <img xml:id="img1" src="image1.jpg" begin="foo.activateEvent" dur="5s"/>   <img xml:id="img2" src="image2.jpg" begin="img1.begin" dur="5s"/>   <img xml:id="img3" src="image3.jpg" begin="img2.begin" dur="5s"/></excl>...</smil>

In the first example, the images are scheduled to begin immediately, wherein the second, they will all begin once the user activates the "foo" element.The end result of the two (other than the begin time) is the same. Given thedefault interrupt semantics forexcl,the first image will begin and then be immediately stopped by the secondimage, which will in turn be immediately stopped by the third image. The netresult is that only the third image is seen, and it lasts for 5 seconds. Notethat the begin and end events for the first two images are raised andpropagated to all time dependents. If the behavior is set to"pause" as in this example, the declared order iseffectively reversed:

<excl>   <priorityClass peers="pause">      <img src="image1.jpg" begin="0s" dur="5s"/>      <img src="image2.jpg" begin="0s" dur="5s"/>      <img src="image3.jpg" begin="0s" dur="5s"/>   </priorityClass></excl>

In this case, the first image will begin and then be immediately paused bythe second image, which will in turn be immediately paused by the thirdimage. The net result is that the third image is seen for 5 seconds, followedby the second image for 5 seconds, followed by the first image for 5 seconds.Note that the begin events for the first two images are raised and propagatedto all time dependents when theexclbegins.

In the following slideshow example, images begin at the earlier of theirscheduled begin time or when activated by a user input event:

<smil ...>...<excl>   <img src="image1.jpg" begin="0s".../>   <img src="image2.jpg" begin="10s; image1.activateEvent".../>   <img src="image3.jpg" begin="20s; image2.activateEvent".../></excl>...</smil>

Note, some surprising results may occur when combining scheduled andinteractive timing within anexcl. Ifin the above example, the user clicks on image1 and then on image2 before tenseconds have elapsed, image 2 will re-appear at the ten second mark. Image 3will appear at twenty seconds. The likely intent of this particular use-casewould be better represented with aseqtime container.

Side effects of activation

This section is informative

Children of theexcl may be activated by scheduled timing,hyperlinks, events or DOM methods calls. For all but hyperlink activation,theexcl time container must be activefor child elements of theexcl to beactivated. With hyperlink activation, the document may be seeked to force theparentexcl to be active, and a seekmay occur to the begin time target child if it has a resolved begin time.That is, the normal hyperlink seek semantics apply to a timed child of anexcl.

With activation via a DOM method call (e.g. thebeginElement() method), the element will be activated at thecurrent time (subject to thepriorityClass semantics), even ifthe element has a scheduled begin time. The exclusive semantics of the timecontainer (allowing only one active element at a time) and allpriorityClass semantics arerespected nevertheless.

This section is informative.

See alsoHyperlinks and timing and specificallyImplications ofbeginElement() and hyperlinking forseq andexcl time containers.

Implicit duration ofmedia element time containers

The implicit duration of a media time container combines the intrinsicduration of the media with the children to define the implicit simpleduration. For the "ID-REF" value ofendsync, the semantics are the same as for a normal time container. For the "media" value of endsync, implicit simpleduration is equal to the intrinsic duration of the media directly associatedwith the element. For the values"first","last" and"all", the mediaelement acts as apar time container,but treats the element's associated media as an additional condition as faras determining when the criteria for"first","last" and"all"endsync values have been satisfied.

Forendsync= {"media" or "ID-REF"}: This is defined as forpar elements.
Forendsync= {"last" or "all"}: The time children and the intrinsic media duration of the associated media define the implicit duration of the media element time container. If the associated media duration is longer than the extent of all the time children, the media duration defines the implicit duration for the media element time container. If the associated media is discrete, this is defined as forpar elements.
Forendsync="first": The time children and the intrinsic media duration define the implicit duration of the media element time container. The element ends when the first active duration ends, as defined above forendsync on apar. If the media is discrete, this is defined as forpar elements.

If the implicit duration defined byendsync islonger than theintrinsic duration for a continuous media element, the ending state of themedia (e.g. the last frame of video) will be shown for the remainder of theimplicit duration. This only applies to visual media - aural media willsimply stop playing.

This section is informative

This semantic is similar to the case in which theauthor specifies a simple duration that is longer than the intrinsic durationfor a continuous media element. Note that for both cases, although the mediaelement is effectively frozen for the remainder of the simple duration, thetime container simple time is not frozen during this period, and any childrenwill run normally without being affected by the media intrinsicduration.

Examples:

This section is informative.

Assume that "vid1" is 10 seconds long in the following examples.

The default value ofendsync formedia elements is "media", and so the simple duration in the followingexample is 10 seconds. This will cut short theanimate child 8 seconds into its simpleduration:

<video src="vid1.mpg" >   <animate begin="2s" dur="12s" .../></video>

Specifyingendsync="first" in the example below causes the simple durationof the video element to be 10 seconds, since the media finishes before theanimate child.

<video src="vid1.mpg" endsync="first" >   <animate begin="2s" dur="12s" .../></video>

Specifyingendsync="last" in the following example causes the simpleduration of the video element to be 14 seconds. The video will show a stillframe (the last frame) for the last 4 seconds of this:

<video src="vid1.mpg" endsync="last" >   <set dur="8s" .../>   <animate begin="2s" dur="12s" .../></video>

Specifyingendsync="all" in the following example causes the simpleduration of the video element to last at least 10 seconds (the intrinsicduration of the video), and at most until 5 seconds after the user clicks onthe video. The video will show a still frame (the last frame) for anyduration in excess of 10 seconds:

<smil ...>...<video src="vid1.mpg" endsync="all" >   <set dur="8s" .../>   <animate begin="activateEvent" dur="5s" .../></video>...</smil>

Thus if the user clicks on the video after 1 second, the simple durationis 10 seconds. If the user does not click until 15 seconds, the simpleduration is 20 seconds, and the last frame will be shown between 10 and 20seconds. The video can still be clicked even though it stops normal play at10 seconds.

Media time containers of other types

This section is informative.

In some language integrations, it will be possible to declare a media timecontainer to have sequence or exclusive semantics, in addition to the defaultparallel semantics described above. For example:

<html ...>...<video xmlns="http://www.w3.org/ns/SMIL" src="vid1.mpg" timeContainer="seq" endsync="first" >   <animate dur="4s" .../>   <animate end="click" .../></video>...</html>

The animate children of thevideowill act in sequence. Theendsyncsemantics define a simple duration for thevideo that is no more than 10 seconds (theintrinsic duration of the video) but may be just over 4 seconds, if the userclicks on thevideo as soon as thelastanimate begins.

5.4.5 Semantics of the Timing Model

Resolving times

A begin or end time is said to be unresolved when either an associatedbegin or end event has not yet occurred (within the constraints ofEvent sensitivity), or the begin or endtime is dependent upon another element's begin or end time that isunresolved. The begin or end time becomes resolved as soon as the syncbaseelement's time is resolved, or when the event occurs (within the constraintsofEvent sensitivity).

If a begin or end value resolves to a time in the past, this value ispropagated to other synchronization dependents. Similarly, a simple or activeduration may be unresolved but may become resolved when end conditions aremet or the parent time container constrains the element's duration.

Definite times

A resolved time is said to bedefinite if it isnot the value "indefinite".

Defining the simple duration

Thesimple duration of an element is determined by thedur attribute, the implicit duration of theelement, and one special-case rule to ensure SMIL 1.0 backward compatibility.Apply the first rule in the table that matches the given criteria.

Computation of the simple duration is based on the information availableat the time the calculation is made. Unresolved quantities may require thesimple duration to be recomputed when an unresolved quantity becomesresolved.

dur	implicit element duration	repeatDur andrepeatCount	Simple Duration
unspecified	(ignored)	unspecified,endspecified	indefinite
Clock-value	(ignored)	(ignored)	dur or Clock-value
indefinite	(ignored)	(ignored)	indefinite
unspecified	resolved	(ignored)	implicit element duration or Clock-value
unspecified	unresolved	(ignored)	unresolved
media	resolved or unresolved	(ignored)	implicit element duration

Simple Duration Table

The repeatCount and unresolved simpleduration

WhenrepeatCount is specified, it isunderstood to represent a count of iterations of simple duration. Eachiteration of the simple duration may be different, and so a simplemultiplication of therepeatCountand a given simple duration may not yield an accurate active duration.In the case of a partial repeatCount and a simple duration that is notresolved, the most recent simple duration should be multiplied by thefractional part of therepeatCount to constrain the lastsimple duration. If the last iteration of the simple duration otherwise endsbefore this time, therepeatCount should be considered to becomplete. If arepeatCount isless than 1 and the simple duration is unresolved, therepeatCount cannot be correctlyrespected, and will behave as though arepeatCount of "1" were specified.

This section is informative

If an element specifying audio media has a simple duration of 0 (e.g.,because ofclipBegin andclipEnd values), nothingshould be played even if therepeatDur specifies an active duration.The time model behaves according to the description, but no audio should beplayed.

If arepeatDur is shorter thanthe simple duration, or ifrepeatCount is less than 1, the activeduration may cut short the defined simple duration.

IfrepeatDur is "indefinite"and neither ofrepeatCount orend are specified, the active durationis indefinite. IfrepeatCount isindefinite, the simple duration is greater than 0 and neither ofrepeatDur orend are specified, then the active duration isindefinite.

Note that unlike in SMIL 1, when an element defines a begin offset andrepeat behavior withrepeatCountorrepeatDur, the begin offset isnot included in each repeat.

Computing the active duration

Theactive duration of an element defines theentire period that an element's timeline is active. It takes into account theelementsimple duration evaluated above, theend attribute, and any repeat behavior definedby therepeatDur andrepeatCount attributes.

Active duration arithmetic rules

Computing the active duration requires definingarithmetic operations on all of the possible values that simple duration mayhave.

Multiplication

zero value * value = zero value
zero value * indefinite = zero value
non-zero value * non-zero value = non-zero value
non-zero value * indefinite = indefinite
indefinite * indefinite = indefinite
unresolved *anything = unresolved

Addition and Subtraction

value +/- value = value
indefinite +/- value = indefinite
value +/- indefinite = indefinite
indefinite +/- indefinite = indefinite
unresolved +/-anything = unresolved
anything +/- unresolved = unresolved

Minimization Function

MIN( zero value, anything) = zero value
MIN( non-zero value, non-zero value) = non-zero value
MIN( non-zero value, indefinite) = non-zero value
MIN( non-zero value, unresolved) = non-zero value
MIN( indefinite, unresolved) = indefinite

Whereanything means zero value, non-zero value, indefinite, orunresolved.

Maximization Function

MAX( numeric value A, numeric value B) = B if B > A, otherwise A
MAX( numeric value, indefinite) = indefinite
MAX( numeric value, unresolved) = unresolved
MAX( indefinite, unresolved) = unresolved

Active duration algorithm

In this section, references tobegin andend values should be understood as the currenteffective values in each respective value list. These values are determinedby the rules described inEvaluation of begin and end timelists.

The following symbols are used in the algorithm as a shorthand:

B: The begin of an element.
d: The simple duration of an element.
PAD: The preliminary active duration of an element, before accounting formin andmax semantics.
AD: The active duration of an element.

Computation of the active duration is based on the information availableat the time the calculation is made. Unresolved quantities may require theactive duration to be recomputed when an unresolved quantity becomesresolved.

To compute the active duration, use the following algorithm:

Ifendis specified, and none ofdur,repeatDur, andrepeatCount are specified, then thesimple duration isindefinitefrom the simpleduration table above, and the active duration is defined by theend value, according to the followingcases:

Ifendis resolved to a value, thenPAD =end -B,
else, ifendisindefinite,thenPAD =indefinite,
else, ifendis unresolved, thenPAD is unresolved, and needs to be recomputed when more information becomes available.

Else, if noendvalue is specified,or the end value is specified asindefinite, thenthe active duration is determined from theIntermediate ActiveDuration computation given below:

PAD =Result from Intermediate Active DurationComputation

Otherwise, anendvalue not equal toindefinite is specified along with at least oneofdur,repeatDur, andrepeatCount. Then thePAD isthe minimum of the result from theIntermediate Active DurationComputation given below and duration betweenend and the element begin:

PAD = MIN(Result from Intermediate Active Duration Computation,end -B)

Finally, the computed active durationAD is obtained by applyingmin andmax semantics to the preliminary activedurationPAD. In the following expression, if there is nomin value, substitute a value of 0, andif there is nomax value, substitute avalue of "indefinite":

AD = MIN(max, MAX(min,PAD ))

Intermediate Active Duration Computation

We define three intermediate quantities, p0, p1, and p2, and produce anintermediate result, theIntermediate Active Duration (IAD)to be used in the computation above.

p0 is the simple duration from the Simple Duration Table, givenabove.

IfrepeatCountis notspecified,p1 has the valueindefinite.Otherwise,p1 is the accumulated sum of the specified number of simpledurations of the iterations of this element.p1 will have a value ofunresolved until the simple duration for each iteration is resolved. Partialiterations will contribute the specified fraction of the simple duration tothe sum. This product can be based on either the known fixed simple durationof the media, or if unknown, the simple duration from the previous iterationof the current set of repetitions. In general for media without a fixedsimple duration,p1 will not be resolved until the specified integralnumber of simple durations has passed.

p2 is the value ofrepeatDur. IfrepeatDur is unspecified, thenp2 will have a value ofindefinite.

ThenIAD is given by:

Ifp0 equals 0, then

IAD =0

Else ifrepeatDurandrepeatCountare unspecifiedthen:

IAD =p0

else:

IAD = MIN(p1,p2,indefinite)

This section is informative

As an example, if an element specifies:

<smil ...>...<audio dur="5s" end="foo.activateEvent" .../>...</smil>

The active duration is initially defined as 5 seconds, based upon thespecified simple duration. If the user activates "foo" before 5 seconds, theend value becomes resolved and theactive duration is re-evaluated. This causes the element to end at the timeof the activation.

Some of the rules and results that are implicit in the algorithm, and thatshould be noted in particular are:

It is possible to have an indefinite simple duration and a defined, finite active duration, or a simple duration that is greater than the active duration. In these cases, the active duration willconstrain (cut short) the simple duration, but the active duration does not re-define the simple duration, or change its value.
If the begin time for an element is not resolved, it may not be possible to compute the simple or active duration.

It is possible to combine scheduled and interactive timing. Forexample:

<smil ...>...<par dur="30s">   <img xml:id="mutebutton" src="mute.jpg"/>   <text  src="description.html" />   <audio src="audio.au" end="mutebutton.activateEvent"/></par>...</smil>

The image and the text appear for the specified duration of thepar (30 seconds). The active duration of theaudio is initially defined to be indefinite because its end time isunresolved. The audio will stop early if the image is activated (e.g.,clicked) before the implicit end of the audio. If the image is not activated,thedur attribute on the parent timecontainer will constrain playback.

It is possible to declare both a scheduled duration, as well as anevent-based active end. This facilitates what are sometimes called "lazyinteraction" use-cases, such as a slideshow that will advance in response touser clicks, or on its own after a specified amount of time:

<smil ...>...<seq>   <img src="slide1.jpg" dur="10s" end="activateEvent" />   <img src="slide2.jpg" dur="10s" end="activateEvent" />   <img src="slide3.jpg" dur="10s" end="activateEvent" />   <!-- etc., etc. --></seq>...</smil>

In this case, the active end of each element is defined to be the earlierof the specified duration, or a click on the element. This lets the viewersit back and watch, or advance the slides at a faster pace.

Paused elements and the activeduration

An element may be paused while it is active. This may happen in a numberof ways, including via a DOM method call or because of excl semantics. Whenan element is paused, a resolved end time for the element may change, or itmay become unresolved. The synchronization relationship between the pausedelement and its parent time container is re-established when the pausedelement is resumed. If for example the element below is paused with a DOMmethod call, there is no way to know when the element will end, and so theend time must be considered unresolved:

<img dur="30s" .../>

However, in the following case, the "bar" element will still end at 10seconds, even if it is paused at 8 seconds. In this case, the end time doesnot change:

<img xml:id="foo" dur="10s" .../><img xml:id="bar" end="foo.end" .../>

Finally, in the following case the "foo" element will initially becomputed to end at 10 seconds. If the "bar" element begins (i.e. if the useractivates or clicks on "foo"), at 8 seconds, "foo" will be paused. However,since the duration of "bar" is known, and the semantics of theexcl pause queue are well defined, the end of"foo" can be computed to be 15 seconds:

<smil ...>...<excl dur="indefinite">   <priorityClass peers="pause">      <img xml:id="foo" dur="10s" .../>      <img xml:id="bar" begin="foo.activateEvent" dur="5s" .../>   </priorityClass></excl>...</smil>

If there is enough information to determine the new end time (as in theexample above), an implementation must compute the correct end time when anelement is paused. Any change to the end time that results from the elementbeing paused must be propagated to any sync arc time dependents (i.e. otherelements with a begin or end defined relative to the active end of the pausedelement). See also thePropagating changesto times section.

In addition, when an element is paused, the accumulated synchronizationoffset will increase to reflect the altered sync relationship. See alsoThe accumulated synchronization offset.

Finally, when an element is paused it may end because the parent timecontainer ends., any fill behavior is interpreted using the element activetime when the element ends (that is, it will use the element active time atwhich it was paused to determine what to display).

Evaluation of begin and endtime lists

This section is informative

Children of par and excl time containers may have multiple begin and endvalues. We need to specify the semantics associated with multiple begin andend times, and how a dynamic timegraph model works with these multipletimes.

The model is based around the idea ofintervals for each element.An interval is defined by a begin and an end time. As the timegraph isplayed, more than one interval may be created for an element with multiplebegin and end times. At any given moment, there is onecurrentinterval associated with each element. Intervals are created byevaluating a list of begin times and a list of end times, each of which isbased upon theconditions described in the begin and end attributesfor the element.

The list of begin times and the list of end times used to calculate newintervals are referred to as lists of "instance times". Each instance time inone of the lists is associated with the specification of a begin or endcondition defined in the attribute syntax. Some conditions - for exampleOffset-values - only have a single instance in the list. Other conditions mayhave multiple instances if the condition can happen more than once. Forexample a Syncbase-value may have multiple instance times if thesyncbase element has played several intervals, and an Event-value mayhave multiple instance times if the event has happened more than once.

The instance times lists for each element are initialized when thetimegraph is initialized, and exist for the entire life of the timegraph.Some instance times such as those defined by Offset-values remain in thelists forever, while others may come and go. For example, times associatedwith Event-values are only added when the associated event happens, and areremoved when the elementresets, as described inResetting element state. Similarly,Instance times for Syncbase-values are added to the list each time a newinterval is created for the syncbase element, but these instance times arenot removed by a reset, and remain in the list.

When the timegraph is initialized, each element attempts to create a firstcurrent interval. The begin time will generally be resolved, but the end timemay often be unresolved. If the element can restart while active, the currentinterval may end (early) at the next begin time. This interval will play, andthen when it ends, the element will review the lists of begin and endinstance times. If the element should play again, another interval will becreated and this new interval becomes thecurrent interval. Thehistory of an element can be thought of as a set of intervals.

Because the begin and end times may depend on other times that can change,the current interval is subject to change, over time. For example, if any ofthe instance times for theend changes while the current interval isplaying, the current interval end will be recomputed and may change.Nevertheless, once a time hashappened, it is fixed. That is, oncethe current interval has begun, its begin time can no longer change, and oncethe current interval has ended, its end time can no longer change. For anelement to restart, it must end the current interval and then create a newcurrent interval to effect the restart.

When a begin or end condition defines a time dependency to another element(e.g. with a Syncbase-value), the time dependency is generally thought of asa relationship between the two elements. This level of dependency isimportant to the model when an element creates a new current interval.However, for the purposes of propagating changes to individual times, timedependencies are more specifically a dependency from a giveninterval ofthe syncbase element to a particularinstance time in one ofthe dependent element's instance time lists. Since only the currentinterval's begin and end times can change, only the current interval willgenerate time-change notices and propagate these to the dependent instancetimes.

When this section refers to the begin and end times for an element, thetimes are described as being in the space of the parent simpleduration. All sync-arcs, event arcs, wallclock values, etc. must beconverted to this time space for easy comparison. This is especiallyimportant when referring to begin times "before 0", which assumes that "0" isthe beginning of the parent simple duration. The model does not depend uponthis definition - e.g. an implementation could do everything in globaldocument time.

Cycles in the timegraph must be detected and broken to ensure reasonablefunctioning of the implementation. A model for how to do this in the generalcase is described (it is actually an issue that applies even to SMIL 1.0). Amechanism to support certain useful cyclic dependencies falls out of themodel.

The rest of this section details the semantics of the instance timeslists, the element life cycle, and the mechanisms for handling dependencyrelationships and cycles.

The instance times lists

Instance lists are associated with each element, and exist for theduration of the document (i.e. there is no life cycle for instancelists). Instance lists may change, and some times may be added and removed,but the begin and end instance times lists are persistent.

Each element may have a begin attribute that defines one or moreconditions that may begin the element. In addition, the timing modeldescribes a set of rules for determining the end of the element, includingthe effects of an end attribute that may have multiple conditions. In orderto calculate the times that should be used for a given interval of theelement, we must convert the begin times and the end times into parent simpletime, sort each list of times (independently), and then find an appropriatepair of times to define an interval.

The instance times may be resolved or unresolved. In the case of the endlist, an additional special value "indefinite" is allowed. The lists aremaintained in sorted order, with "indefinite" sorting after all otherresolved times, and unresolved times sorting to the end.

For begin, the list interpretation is straightforward, since begin timesare based only upon the conditions in the attribute or upon the default beginvalue if there is no attribute. However, when a begin condition is aSyncbase-value, the syncbase element may have multiple intervals, and we mustaccount for this in the list of begin times associated with theconditions.

For end, the case is somewhat more complex, since the end conditions areonly one part of the calculation of the end of the active duration. Theinstance times list for end are used together with the other SMIL Timingsemantics to calculate the actual end time for an interval.

If an instance time was defined as Syncbase-values, the instance time willmaintain a time dependency relationship to the associated interval for thesyncbase element. This means that if the associated begin or end time of thesyncbase current interval changes, then the dependent instance time for thiselement will change as well.

When an element creates a new interval, it notifies time dependents andprovides the begin and end times that were calculated according to thesemantics described in "Computing the active duration". Each dependentelement will create a new instance time tied to (i.e. with a dependencyrelationship to) the new syncbase current interval.

Building the instance times lists

The translation of begin or end conditions to instance times depends uponthe type of condition:

Offset-values are the simplest. Each Offset-value condition yields a single instance time. This time remains in the list forever, and is unaffected by reset of the element, or by repeat or restart of the parent (or other ascendants).
Wallclock-sync-values are similar to offset values. Each Wallclock-sync-value condition yields a single instance time. This time remains in the list forever, however each time an ascendant restarts or repeats, these times arereconvertedfrom the wallclock time space to the new parent simple time space.
Event-values,Accesskey-values andRepeat-values are all treated similarly. These conditions do not yield an instance time unless and until the associated event happens. Each time the event happens, the condition yields a single instance time. The event time plus or minus any offset isadded to the list. If the event happens multiple times during a parent simple duration, there may be multiple instance times in the list associated with the event condition. However, an important distinction is that event times are cleared from the list each time the element is reset (see alsoResetting element state). Within this section, these three value types are referred to collectively asevent value conditions.
Syncbase-values andMedia-Marker-values are treated similarly. These conditions do not yield an instance time unless and until the associated syncbase element creates an interval. Each time the syncbase element creates a new interval, the condition yields a single instance time. The time plus or minus any offset isadded to the list. Unlike event times, syncbase times arenot cleared from the element's lists simply because the element is reset. Instead, a resolved syncbase time is removed from the list when a common ascendant of the syncbaseand the dependent element restarts or repeats. Also each time an ascendant restarts or repeats, the remaining syncbase times are re-converted from the syncbase time space to the new parent simple time space, since syncbase times are always relative to the current parent simple time space (see alsoResetting element state). Within this section, these three value types are referred to collectively assyncbase value conditions.
The special value"indefinite" does not yield an instance time in the begin list. It will, however yield a single instance with the value "indefinite" in an end list. This value is not removed by a reset.

If no attribute is present, the default begin values must be evaluated.For children of par, this is equivalent to an Offset-value of 0, and yieldsone persistent instance value. For children of excl, this is equivalent to"indefinite", and so does not yield an instance value.

If a DOM method call is made to begin or end the element(beginElement(), beginElementAt(),endElement() or endElementAt()), each method callcreates a single instance time (in the appropriate instance times list).These time instances are cleared upon reset just as for event times. SeeResetting element state.

When a new time instance is added to the begin list, the current intervalwill evaluate restart semantics and may ignore the new time or it may end thecurrent interval (this is detailed inInteraction with restart semantics). Incontrast, when an instance time in the begin list changes because thesyncbase (current interval) time moves, this does not invoke restartsemantics, but may change the current begin time: If the current interval hasnot yet begun, a change to an instance time in the begin list will cause are-evaluation of the begin instance lists, which may cause the interval begintime to change. If the interval begin time changes, atime-changenotice must be propagated to all dependents, and the current interval endmust also be re-evaluated.

When a new instance time is added to the end list, or when an instancetime in the end list changes, the current interval will re-evaluate its endtime. If it changes, it must notify dependents.

If an element has already played all intervals, there may be no currentinterval. In this case, additions to either list of instance times, as wellas changes to any instance time in either list cause the element tore-evaluate the lists just as it would at the end of each interval (asdescribed inEnd of an interval below).This may or may not lead to the creation of a new interval for theelement.

When times are added to the instance times lists, they may or may not beresolved. If they are resolved, they will be converted to parent simple time.If an instance time changes from unresolved to resolved, it will be similarlyconverted.

There is a difference between an unresolved instance time, and a begin orend condition that has no associated instance. If, for example, an eventvalue condition is specified in the end attribute, but no such event hashappened, there will be no associated instance time in the end list. However,if a syncbase value condition is specified for end, and if the syncbaseelement has a current interval, there will be an associated instance time inthe end list. Since the syncbase value condition may be relative to the endof the syncbase element, and since the end of the syncbase current intervalmay not be resolved, the associated instance time in the end list may beunresolved. Once the syncbase current interval actually ends, the dependentinstance time in the end list will get a time-change notification for theresolved syncbase interval end. The dependent instance time will convert thenewly resolved syncbase time to a resolved time in parent simple time. If theinstance lists did not include the unresolved instance times, some additionalmechanism would have to be defined to add the end instance time when thesyncbase element's current interval actually ended, and resolved its endtime.

The list of resolved times includes historical times defined relative tosync base elements, and so can grow over time if the sync base has manyintervals. Implementations may filter the list of times as an optimization,so long as it does not affect the semantics defined herein.

Principles for building and pruning intervals

This section is informative

The following set of principles underlie the interval model. This is not acomplete model - it is just meant provide an additional view of the model.

First we define the termspruning andcutting off aninterval - these concepts should not be confused.

In some cases, after an interval has been created, it must later bepruned (deleted/removed from the timegraph) as more informationbecomes known and semantic constraints must be applied. When an interval ispruned, it will not be shown, it will not raise begin or end events,and any associated instance times for syncbase time dependents must beremoved from the respective instance times lists. It is as though thepruned interval had not been specified.

In other cases, especially related to negative begin times on parent timecontainers, a valid interval for a child may not be shown, even though it isotherwise legal with respect to the parent time constraints. For example:

<par begin="-10s" dur="20s">   <img xml:id="slide1" src="slide1.jpg" dur="3s" />   <img xml:id="slide2" src="slide2.jpg" begin="slide1.end+3s" dur="10s" />   <img xml:id="note1" src="note1.jpg" begin="slide1.beginEvent" dur="20s" /></par>

The "slide1" image will becut off, but is notpruned.It iscut offbecause the par could not have been started 10s beforeits parent time container, and instead will be started at 0s into its parenttime synced at 10s into its simple duration. The "slide1" image begins andends before 10s into the par, and so cannot be shown and iscut off,Intervals that arecut offare not shown and do not raise begin orend events, but still create valid instance times for any syncbase timedependents. Thus, "slide2" will be shown (the interval is fromminus 4 seconds to 6 seconds, document time, and so will be shown for 6seconds, from 0 seconds to 6 seconds), but "note1" will not be shown.

The principles underlying the interval life cycle model are:

Try to build the current interval as early as possible.
1. The "next" interval can be computed no earlier than the end of the current interval.
Do not change any interval time that is in the past. Do not prune an interval that has already begun. Note that this refers tointervals and notinstance times.
When building an interval from a set of instance times, if the duration is resolved and negative, reject the interval; do not propagate the interval to time dependents.
1. When the current interval has not yet begun, if the interval times change such that the duration is negative, prune the interval.
When building an interval from a set of instance times, if the end is resolved and is <= 0 (in parent simple time), reject the interval; do not propagate the interval to time dependents.
1. When the current interval has not yet begun, if the interval times change such that the end is <= 0, prune the interval.
When building an interval from a set of instance times, if the interval begin is >= the (resolved) simple end of the parent time container, reject the interval.
1. When the current interval has not yet begun, if the interval times change such that the begin is >= the parent time container simple end, prune the interval.
2. When the current interval has not yet begun, if the parent simple end time changes such that the current interval begin is >= the parent time container simple end, prune the interval.

An implication of principle 5 is that we will get no intervals withunresolved begin times, since these will necessarily compare>= the parent simple end.

Element life-cycle

The life cycle of an element can be thought of as the following basicsteps:

Startup - getting the first interval
Waiting to begin the current interval
Active time - playing an interval
End of an interval - compute the next one and notify dependents
Post active - perform any fill and wait for any next interval

Steps 2 to 5 can loop for as many intervals as are defined before the endof the parent simple duration. At any time during step 2, the begin time forthe current interval may change, and at any time during steps 2 or 3, the endtime for the current interval may change. When either happens, the changesare propagated to time dependents.

When the document and the associated timegraph are initialized, theinstance lists are empty. The simple offset values and any "indefinite" valuein an end attribute can be added to the respective lists as part ofinitialization, as they are independent of the begin time of parent simpletime.

When an element has played all allowed instances, it can be thought of asstuck in step 5. However any changes to the instance lists during this periodcause the element to jump back to step 4 and consider the creation of a newcurrent interval.

Startup - getting the first interval

An element life cycle begins with the beginning of the simple duration forthe element's parent time container. That is, each time the parent timecontainer (or more generallyanyascendant time container) repeatsor restarts, the element resets (see alsoResetting element state) and starts"life" anew.

Three things are important about the beginning of the life-cycle:

Any and all resolved times defined as Event-values, Repeat-values, Accesskey-values or added via DOM method calls are cleared.
Any and all resolved times defined as Syncbase-values, Wallclock-sync-values or Media-Marker-values must be reconverted from the syncbase time space to the parent simple time space.
The first current interval is computed.

Action 1) is also described inResetting element state. This actionalso happens each time the element restarts, although in that case theelement must not clear an event time that defined the current begin of theinterval.

Action 2) Simply updates values to reflect the current sync relationshipof the parent simple duration to the rest of the document.

The third action requires some special consideration of the lists oftimes, but is still relatively straightforward. It is similar to, but not thesame as the action that applies when the element ends (this is described inEnd of an interval). The basic idea isto find the first interval for the element, and make that the currentinterval. However, the model should handle three edge cases:

The element may begin before the parent simple begin time (i.e. before 0 in parent simple time), and so appears to begin part way into the local timeline (somewhat like a clipBegin effect on a media element). The model must handle begin times before the parent begin.
The element has one or more intervals defined that beginand end before the parent simple begin (before 0). These are filtered out of the model.
The element has one or more intervals defined that begin after the parent simple end. These are filtered out of the model. Note that if the parent simple end is unresolved, any resolved begin time happens before the parent simple end.

Thus the strict definition of the first acceptable interval for theelement is the first interval that ends after the parent simple begin, andbegins before the parent simple end. Here is some pseudo-code to get thefirst interval for an element. It assumes an abstract type "Time" thatsupports a compare function. It may be a resolved numeric value, the specialvalue INDEFINITE (only used with end), and it may be the special valueUNRESOLVED. Indefinite compares "greater than" all resolved values, andUNRESOLVED is "greater than" both resolved values and INDEFINITE. The codeuses the instance times lists associated with the begin and end attributes,as described in the previous section.

// Utility function that returns true if the end attribute specification// includes conditions that describe Event-values, Repeat-values or Accesskey-values.boolean endHasEventConditions();// Calculates the first acceptable interval for an element// Returns://    Interval if there is such an interval//    FAILURE if there is no such intervalInterval getFirstInterval(){Time beginAfter=-INFINITY;while( TRUE ) // loop till return{   If (currentInterval.end > currentInterval.begin)
       Set tempBegin = the first value in the begin list that is >= beginAfter.
   Else
       Set tempBegin = the first value in the begin list that is > beginAfter.
   If there is no such value  // No interval      return FAILURE;   If tempBegin >= parentSimpleEnd // Can't begin after parent ends      return FAILURE;   If there was no end attribute specified      // this calculates the active end with no end constraint      tempEnd = calcActiveEnd( tempBegin );   else   {      // We have a begin value - get an end      Set tempEnd = the first value in the end list that is >= tempBegin.      // Allow for non-0-duration interval that begins immediately      // after a 0-duration interval.      If tempEnd == tempBegin && tempEnd has already been used in         an interval calculated in this method call      {         set tempEnd to the next value in the end list that is > tempEnd      }               If there is no such value      {         // Events leave the end open-ended. If there are other conditions         // that have not yet generated instances, they must be unresolved.         if endHasEventConditions()            OR if the instance list is empty            tempEnd = UNRESOLVED;         // if all ends are before the begin, bad interval         else            return FAILURE;      }      // this calculates the active dur with an end constraint      tempEnd = calcActiveEnd( tempBegin, tempEnd );   }   // We have an end - is it after the parent simple begin?   // Handle the zero duration intervals at the parent begin time as a special case   if( tempEnd > 0 || (tempBegin==0 && tempEnd==0))      return( Interval( tempBegin, tempEnd ) );   else      // Change beginAfter to find next interval, and loop      beginAfter = tempEnd;} // close while loop} // close getFirstInterval

Note that while we might consider the case ofrestart="always"separately fromrestart="whenNotActive", it would just be busywork since we need to find an interval that beginsaftertempEnd.

If the model yields no first interval for the element, it will neverbegin, and so there is nothing more to do at this point. However if there isa valid interval, the element must notify all time dependents that there is anew interval of the element. This is a notice from this element toall elements that are direct time dependents. This is distinct from thepropagation of a changed time.

When a dependent element gets a "new interval" notice, this includes areference to the new interval. The new interval will generally have aresolved begin time and may have a resolved end time. An associated instancetime will be added to the begin or end instance time list for the dependentelement, and this new instance time will maintain a time dependencyrelationship to the syncbase interval.

Waiting to begin the interval

This period only occurs if the current interval does not begin immediatelywhen (or before) it is created. While an interval is waiting to begin, anychanges to syncbase element current interval times will be propagated to theinstance lists and may result in a change to the current interval.

If the element receives a "new interval" notice while it is waiting tobegin, it willaddthe associated time (i.e. the begin or end timeof the syncbase interval) to the appropriate list of resolved times.

When an instance time changes, or when a new instance time is added to oneof the lists, the element will re-evaluate the begin or end time of thecurrent interval (using the same algorithm described in the previoussection). If this re-evaluation yields a changed interval, time changenotice(s) will be sent to the associated dependents.

It is possible during this stage that the begin and end times could changesuch that the interval would never begin (e.g. the interval end is before theinterval begin). In this case, the interval must bepruned and alldependent instance times must be removed from the respective instance listsof dependent elements. These changes to the instance lists will causere-evaluation of the dependent element current intervals, in the same manneras a changed instance time does.

This section is informative.

One exception to normal processing is made forelements that aredeferred according toexcl interrupt semantics: a deferred elementignores propagated changes to its begin time. This is detailed in theDeferred elements and propagatingchanges to begin section.

Active time - playing an interval

This period occurs when the current interval is active (i.e. once it hasbegun, and until it has ended). During this period, the end time of theinterval may change, but the begin time cannot. If any of the instance timesin the begin list change after the current interval has begun, the changewill not affect the current interval. This is different from the case ofadding a new instance time to the begin list, whichcancause a restart.

If the element receives a "new interval" notice while it is active, itwilladdthe associated time (i.e. the begin or end time of thesyncbase interval) to the appropriate list of resolved times. If the newinterval adds a time to the begin list, restart semantics are considered, andthis may end the current interval.

Ifrestart is set to"always", then the current interval will end earlyif there is an instance time in the begin list that is before (i.e. earlierthan) the defined end for the current interval. Ending in this manner willalso send a changed time notice to all time dependents for the currentinterval end. See alsoInteraction withrestart semantics.

End of an interval

If an element specifiesrestart="never" then no furtheraction is taken at the end of the interval, and the element sits in the "postinterval" state unless and until an ascendant time container repeats orrestarts.

If an element specifies other values forrestart, when itends the current interval the element must reconsider the lists of resolvedbegin and end times. If there is another legal interval defined to begin ator after the just completed end time, a new interval will be created. When anew interval is created it becomes thecurrent interval and a newinterval notice is sent to all time dependents.

The algorithm used is very similar to that used in step 1, except that weare interested in finding an interval that begins after the most recentend.

// Calculates the next acceptable interval for an element// Returns://    Interval if there is such an interval//    FAILURE if there is no such intervalInterval getNextInterval(){// Note that at this point, the just ended interval is still the "current interval"Time beginAfter=currentInterval.end;   Set tempBegin = the first value in the begin list that is >= beginAfter.   If there is no such value  // No interval      return FAILURE;   If tempBegin >= parentSimpleEnd // Can't begin after parent ends      return FAILURE;   If there was no end attribute specified      // this calculates the active end with no end constraint      tempEnd = calcActiveEnd( tempBegin );   else   {      // We have a begin value - get an end      Set tempEnd = the first value in the end list that is >= tempBegin.      // Allow for non-0-duration interval that begins immediately      // after a 0-duration interval.      If tempEnd == currentInterval.end      {         set tempEnd to the next value in the end list that is > tempEnd      }               If there is no such value      {         // Events leave the end open-ended. If there are other conditions         // that have not yet generated instances, they must be unresolved.         if endHasEventConditions()            OR if the instance list is empty            tempEnd = UNRESOLVED;         // if all ends are before the begin, bad interval         else            return FAILURE;      }      // this calculates the active dur with an end constraint      tempEnd = calcActiveEnd( tempBegin, tempEnd );   }   return( Interval( tempBegin, tempEnd ) );} // close getNextInterval

Post active

This period can extend from the end of an interval untilthe beginning of the next interval, or until the end of the parent simpleduration (whichever comes first). During this period, any fill behavior isapplied to the element. The times for this interval can no longer change.Implementations may as an optimization choose to break the time dependencyrelationships since they can no longer produce changes.

Interaction with restart semantics

There are two cases in which restart semantics must be considered:

When the current interval is playing, ifrestart="always" then any instance time (call itT) in the begin list that is after (i.e. later than) the current interval begin but earlier than the current interval end will cause the current interval to end at timeT. This is the first step in restarting the element: when the current interval ends, that in turn will create any following interval.
When a new instance time is added to the begin list of instance times, restart rules may apply. The new instance times may result from a begin condition that specifies one of the syncbase value conditions, for which a new instance notice is received. It may also result from a begin condition that specifies one of the event value conditions, for which the associated event happens.
In either case, the restart setting and the state of the current interval controls the resulting behavior. The new instance time is computed (e.g. from the syncbase current interval time or from the event time, and including any offset), and added to the begin list. Then:
- If the current interval is waiting to play, the element recalculates the begin and end times for the current interval, as described in theElement life-cycle step 1 (for the first interval) or step 4 (for all later intervals). If either the begin or end time of the current interval changes, these changes must be propagated to time dependents accordingly.
- If the current interval is playing (i.e. it is active), then therestart setting determines the behavior:
  - Ifrestart="never" then nothing more is done. It is possible (if the new instance time is associated with a syncbase value condition) that the new instance time will be used the next time the element life cycle begins.
  - Ifrestart="whenNotActive"then nothing more is done. If the time falls within the current interval, the element cannot restart, and if it falls after, then the normal processing at the end of the current interval will handle it. If the time falls before the current interval, as can happen if the time includes a negative offset, the element does not restart (the new instance time is effectively ignored).
  - Ifrestart="always" then case 1 above applies, and will cause the current interval to end.

Cyclic dependencies in the timegraph

There are two types of cycles that can be created with SMIL 3.0,closed cycles andopen orpropagating cycles. Aclosed cycle results when a set of elements has mutually dependenttime conditions, and no other conditions on the affected elements can affect or change this dependency relationship, as in examples 1 and 2 below. Anopen orpropagating cycle results when a set of elementshas mutually dependent time conditions, but at least one of the conditionsinvolved has more than one resolved condition. If any one of the elements inthe cycle can generate more than one interval, the cycle can propagate. Insome cases such as that illustrated in example 3, this can be very useful.

Times defined in a closed cycle are unresolved, unless some externalmechanism resolves one of the element time values (for example a DOM methodcall or the traversal of a hyperlink that targets one of the elements). Ifthis happens, the resolved time will propagate through the cycle, resolvingall the associated time values.

Closed cycles are an error, and may cause the entire document to fail. Insome implementations, the elements in the cycle may just not begin or endcorrectly. Examples 1 and 2 describe the most forgiving behavior, butimplementations may simply reject a document with a closed cycle.

Detecting Cycles

Implementations can detect cycles in the timegraph using avisited flag on each element as part of the processing thatpropagates changes to time dependents. As a changed time notice ispropagated, each dependent element is marked as having beenvisited.If the change to a dependent instance time results in a change to the currentinterval for that element, this change will propagate in turn to itsdependents. This secondchainednotice happens in the context of thefirst time-change notice that caused it. The effect is like a stack thatbuilds as changes propagate throughout the graph, and then unwinds when allchanges have propagated. If there is a dependency cycle, the propagation pathwill traverse an element twice during a given propagation chain. This is acommon technique used in graph traversals.

A similar approach can be used when building dependency chains duringinitialization of the timegraph, and when propagating new interval notices -variations on the theme will be specific to individual implementations.

When a cycle is detected, the change propagation is ignored. The elementthat detected the second visit ignores the second change notice, and sobreaks the cycle.

Examples

This section is informative.

Example 1: In the following example, the 2 images define begin times thatare mutually dependent. There is no way to resolve these, and so the imageswill never begin.

<img xml:id="foo" begin="bar.begin" .../><img xml:id="bar" begin="foo.begin" .../>

Example 2: In the following example, the 3 images define a less obviouscycle of begin and end times that are mutually dependent. There is no way toresolve these. The image "joe" will begin but will never end, and the images"foo" and "bar" will never begin.

<img xml:id="foo" begin="joe.end" .../><img xml:id="bar" begin="foo.begin" dur="3s" .../><img xml:id="joe" begin="0" end="bar.end" .../>

Example 3: In the following example, the 2 images define begin times thatare mutually dependent, but the first has multiple begin conditions thatallow the cycle to propagate forwards. The image "foo" will first bedisplayed from 0 to 3 seconds, with the second image "bar" displayed from 2to 5 seconds. As each new current interval of "foo" and "bar" are created,they will add a new instance time to the other element's begin list, and sothe cycle keeps going forward. As this overlapping "ping-pong" behavior isnot otherwise easy to author, these types of cycles are not precluded.Moreover, the correct behavior will fall out of the model described above.

<img xml:id="foo" begin="0; bar.begin+2s" dur="3s" .../><img xml:id="bar" begin="foo.begin+2s" dur="3s" .../>

Example 4: In the following example, an open cycle is described thatpropagates backwards. The intended behavior does not fall out of the model,and is not supported. In this example, however, each time the parent timecontainer repeats, the video elements will begin two seconds earlier thanthey did in the previous parent iteration. This is because the begin instancetimes associated with syncbase value conditions are not cleared when theparent repeats. By the last iteration of the parent time container, bothvideo elements would begin so early that they will be completely cut off bythe parent begin constraint.

<par dur="10s" repeatCount="11" >   <video xml:id="foo" begin="0; bar.begin-1s" dur="10s" .../>   <video xml:id="bar" begin="foo.begin-1s" dur="10s" .../></par>

Timing and real-world clocktimes

This section is informative

In this specification, elements are described ashaving local "time". In particular, many offsets are computed in the simpletime of a parent time container. However, simple durations may be repeated,and elements may begin and restart in many ways.

There is no direct relationship between the local "time" for an element, and the real world concept of time as reflected on a clock.

Interval timing

This section is informative

The SMIL timing model assumes the most common modelforinterval timing.

Interval timing describes intervals of time (i.e. durations) in which the begin time of the interval is included in the interval, but the end time is excluded from the interval.

This section is informative

This is also referred to asend-pointexclusive timing. This model makes arithmetic for intervals workcorrectly, and provides sensible models for sequences of intervals.

Background rationale

This section is informative.

In the real world, this is equivalent to the way that seconds add up tominutes, and minutes add up to hours. Although a minute is described as 60seconds, a digital clock never shows more than 59 seconds. Adding one moresecond to "00:59" does not yield "00:60" but rather "01:00", or 1 minute and0 seconds. The theoretical end time of 60 seconds that describes a minuteinterval is excluded from the actual interval.

In the world of media and timelines, the same applies: Let "A" be a video,a clip of audio, or an animation. Assume "A" begins at 10 and runs until 15(in any units - it does not matter). If "B" is defined to follow "A", then itbegins at 15 (and not at 15 plus some minimum interval). When a runtimeactually renders out frames (or samples for audio), and must render the time"15", it should not show both a frame of "A" and a frame of "B", but rathershould only show the new element "B". This is the same for audio, or for anyinterval on a timeline. If the model does not use endpoint-exclusive timing,it will draw overlapping frames, or have overlapping samples of audio, ofsequenced animations, etc.

Note that transitions from "A" to "B" also adhere to the interval timingmodel. Theydo require that "A" not actually end at 15, and thatboth elements actually overlap. Nevertheless, the "A" duration is simplyextended by the transition duration (e.g. 1 second). This new duration for"A" isalso endpoint exclusive - at the end of this new duration,the transition will be complete, and only "B" should be rendered - "A" is nolonger needed.

Implications for the time model

This section is informative.

For the time model, several results of this are important: the definitionof repeat, and the state of the element applied or displayed when the elementis "frozen".

When repeating an element's simple duration, the arithmetic follows theend-point exclusive model. Consider the example:

<video dur="4s" repeatCount="4" .../>

At time 0, the simple duration is also at 0, and the first frame of videois presented. This is theinclusive begin of the interval. Thesimple duration proceeds normally up to 4 seconds.

The appropriate way to map time on the active duration to time on the simple duration is to use the remainder of division by the simple duration:
simpleTime = REMAINDER( t,d ) where t is within the active duration
Note: REMAINDER( t, d ) is defined ast - (d*floor(t/d))

This section is informative.

Using this, a time of4 (or 8 or 12) maps to the time of0 on the simple duration. The endpoint of the simpleduration isexcluded from (i.e. not actually sampled on) the simpleduration.

For most continuous media, this aligns to the internal media model, and sono frames (or audio samples) are ever excluded. However for sampled timelinemedia (like animation), the distinction is important, and requires a specificsemantic for elements that are frozen.

If the active duration is an integer multiple of the simple duration, the media to show when frozen is the last frame (or last value) defined for the simple duration.

This section is informative.

The effect of this semantic upon animation functionsis detailed in theSMIL 3.0 Animation chapter.

Event sensitivity

This section is informative

The SMIL 3.0 timing model supports synchronization based uponunpredictable events such as DOM events or user interface generated events.The model for handling events is that the notification of the event isdelivered to the timing element, and the timing element uses a set of rulesto resolve any synchronization dependent upon the event.

Note:

The SMIL 3.0 test suite contains many examples of event-based timing, and states the preferred behavior for these tests. However, it is acknowledged that the timing of event propagation is implementation dependent, and so there are occasions in which delivery of an event may not occur because an intervening state change in the timegraph precludes event delivery (as perthe event sensitivity rules). That is, after the event generation but before the event dispatch and handling something else in the timegraph is evaluated which precludes event delivery. This includes the internally generated timing events beginEvent, endEvent, and repeatEvent, as well as externally generated events such as the focusInEvent and focusOutEvent.
In these cases, it is desirable for model implementations to behave as if they responded to the internal timing events instantaneously, but an implementation is considered conformant if event propagation delay precludes this behavior.
For example, intiming test case 1.15, the delivery of the image1.beginEvent to the image2 element may not occur until after the par has ended at 3s (due to image1 having 0 duration and no other children of the par with resolved begin times), and so it is also compliant behavior for the image1 element to show for 0 seconds and then for the par to end.

The semantics of element sensitivity to events are described by thefollowing set of rules:

While a time container is not active (i.e. before the time container begin or after the time container active end), child elements donotrespond to events (with respect to the Time model). Note that while a parent time container is frozen, it is not active, and so children do not handle begin or end event specifications.
1. If an element and an ascendant time container are both specified to begin with the same event, the behavior is not predictable (based upon DOM event semantics). Authors are discouraged from authoring these cases.
If an element is not active (but the parent time container is), then events are only handled for begin specifications. Thus if an event is raised andbegin specifies the event, the element begins. While the element is not active, anyend specification of the event is ignored.
If an element is (already) active when an event is raised, andbegin specifies the event, then the behavior depends upon the value ofrestart:
1. Ifrestart="always", then a new begin time is resolved for the element based on the event time. Any specification of the event inend is ignored for this event instance.
2. Ifrestart="never" orrestart="whenNotActive", then anybegin specification of the event is ignored for this instance of the event. Ifend specifies the event, an end value is resolved based upon the event time, and the active duration is re-evaluated (according to the rules inComputing the active duration).

It is important to notice that in no case is a single event occurrenceused to resolve both a begin and end time on the same element.

This section is informative

Rule 1a discourages the use of cases such as the following:

<smil ...>...<par xml:id="bad_example" begin="link9.activateEvent">   <img begin="link9.activateEvent" .../></par>...</smil>

Various alternative approaches can be used. One possible approach is todefine the descendant element to begin relative to the ascendant begin, as inthe following example (the begin rule for the image could be simpler, butthis illustrates the general point):

<smil ...>...<par xml:id="better_example" begin="link9.activateEvent">   <img begin="better_example.begin" .../></par>...</smil>

The event sensitivity rules may be used with therestart attribute todescribe "toggle" activation use cases, as described in the section:Using restart for toggleactivation.

Since the same event instance cannot be used to resolve both the begin andend time on a single element, uses like the following will have behavior thatmay seem non-intuitive to some people:

<smil ...>...<audio src="bounce.wav" begin="foo.activateEvent"         end="foo.activateEvent+3s" restart="whenNotActive"/>...</smil>

This example will begin repeating the audio clip when "foo" is clicked,and stop the audio clip 3 seconds after "foo" is clickeda secondtime. It is incorrect to interpret this example as playing the audioclip for 3 seconds after "foo" is clicked. For that behavior, the followingmarkup should be used:

<smil ...>...<audio src="bounce.wav" begin="foo.activateEvent" dur="3s"        restart="whenNotActive"/>...</smil>

User event sensitivity and timing

The timing model and the user event model are largely orthogonal. Whilethe timing model does reference user events, it does not define how theseevents are generated, and in particular does not define semantics of keyboardfocus, mouse containment, "clickability", and related issues. Because timingcan affect the presentation of elements, it may impact the rules for userevent processing, however it only has an effect to the extent that thepresentation of the element is affected.

In particular, many user event models will make no distinction between anelement that is "playing" and one that is "frozen". The effects of thefill attribute apply only to the timingsemantics. If an element is still visible while frozen, it behaves normallywith respect to other semantics such as user event processing. In particular,elements such asa andarea are still sensitive to user activation(e.g. clicks) when frozen.

Link Activation compared to Event activation

This section is informative.

Related to event-activation islink-activation. Hyperlinking has defined semantics in SMIL 1.0 toseek a document to a point in time. When combined with interactive timing(e.g.begin="indefinite"), hyperlinking yields a variant onuser-interactive content.

A hyperlink may be targeted at an element that does not have a scheduled begin time.
When the link is traversed, the element begins.
Note that unlike event activation, the hyperlink activation is not subject to the constraints of the parent time container.

This section is informative.

The details of when hyperlinks activate an element,and when they seek the document timeline are presented in the sectionHyperlinks and timing.

Converting between local andglobal times

To convert a document time to an element local time, the original time isconverted to a simple time for each time container from the root timecontainer down to the parent time container for the element. This recursivealgorithm allows for a simple model of the conversion from parent simple timeto element active and element simple time. The first step calculates elementactive time, and the second step calculates element simple time.

The steps below assume that the associated times are resolved and notindefinite. If a required time is not resolved or is indefinite, then theconversion is not defined, and cannot be performed.

Element active time calculation

The input time is a time in parent simple time. This is normalized to theelement active duration, adjusting for the accumulated synchronization offset(described inThe accumulatedsynchronization offset).

Lett_ps be a time in parent simple time,B be the begin time for an element, andO be the accumulated synchronization offset for an element, measured in parent simple time.
The element active timet_a for any child element is:
t_a =t_ps - B - O

Element simple time calculation

The element simple time is the time that is used to establish runtimesynchronization for a media element, or to compute an animation function'sinput value or sampling time. If the element is a time container, this isalso the time that is seen by all children of a time container (as the timecontainer element's simple time).

To compute the element simple timet_s from anelement active timet_a, accounting for any repeatbehavior:

If there is no repeating behavior:
t_s = t_a
Else, the element simple time is just computed from the begin time of the most recent iteration - call thist_last-repeat. Some other mechanism (such as endsync logic or a media player) must note when the simple duration ends, and reset the value oft_last-repeat. If the element has not yet repeated, a value of 0 is used in place oft_last-repeat.
t_s = t_a - t_last-repeat

Note that the above semantic covers the special (ideal) case when thesimple durationdur is fixed and does not vary. In this case(and this case only)t_last-repeat may be obtaineddirectly for the simple durationdur and so the expressionmay be reduced to:

t_s = REMAINDER( t_a, dur )
whereREMAINDER( t, d ) is defined as(t - d*floor(t/d)).

Converting wall-clock values

When the document begins, the current wall-clock time is noted and savedast_{wallclock-begin}. To convert a wall-clockvaluet_wc to an element active simple timet_s, first convertt_wcto a document global timet_ra (i.e. an elementactive time for the root time container):

t_ra = t_wc - t_{wallclock-begin}

This may yield a negative time if the wallclock value is a time before thedocument began. Nevertheless, this is a legal value.

The timet_rais then converted normally toelement active time or element local time as needed.

Converting from event time to element time

Event times are generally stamped with a time relative to system time orwhen the document began. The conversion is as for wallclock values, in thatthe event time is converted to an active time for the root time container,and then converted normally to an element time.

Converting from element time to element time

To convert from one element timespace to another, the time for the firstelementt_e1 must first be converted to a simpletime on the closest ascendant time container that contains both elements.Converting from an element time to the parent time reverses the processdescribed above. Again, it is recursive, and so the conversions are describedgenerically from element simple to element active time, and from elementactive to parent simple time.

To convert from element simple time to element active time requires thebegin time of the most recent iteration,t_last-repeat. If the element does not repeat orhas not yet repeated, a value of 0 is used in place oft_last-repeat.

t_a = t_s +t_last-repeat

Conversion from element active time to parent simple time uses theassociated begin of the element and the accumulated synchronizationoffset.

t_ps =t_a + B +O

Time conversions and sampling the time graph

This section is informative.

Note that the pure conversions do not take intoaccount the clamping of active durations, nor the effects of fill (where timeis frozen).

Global to local time conversions used to translatebetween timespaces must ignore these issues, and so may yield a time in thedestination local timespace that is well before or well after the simpleduration of the element.

This section is informative.

An alternate form of the conversion is used whenactually sampling the time graph.

A time container is only sampled if it is active orfrozen, and so no times will be produced that are before a time containerbegins. If the global to local time conversion for a time container yields atime during which the time container is frozen, the time is clamped to thevalue of the active end.

Hyperlinks and timing

This section is informative

Hyperlinking semantics must be specifically definedwithin the time model in order to ensure predictable behavior. Earlierhyperlinking semantics, such as those defined by SMIL 1.0 are insufficientbecause they do not handle unresolved times, nor do they handle author-timerestart restrictions. Here we extend SMIL 1.0 semantics for use inpresentations using elements with unresolved timing (including interactivetiming) and author-time restart restrictions.

A hyperlink may be targeted at an element by specifying the value of theid attribute of an element in thefragment part of the link locator. Traversing a hyperlink that refers to atimed element will behave according to the following rules:

If the target element is active, seek the document time back to the begin time of the current interval for the element.
Else if the target element begin time is resolved (i.e. there is at least one interval defined for the element), seek the document time (forward or back, as needed) to the begin time of the first interval for the target element. Note that the begin time may be resolved as a result of an earlier hyperlink, DOM or event activation. Once the begin time is resolved (and until the element is reset, e.g. when the parent repeats), hyperlink traversal always seeks. For a discussion of "reset", seeResetting element state. Note also that for an element begin to be resolved, the begin time of all ancestor elements must also be resolved.
Else (i.e. there are no defined intervals for the element), the target element begin time must be resolved. This may require seeking and/or resolving ancestor elements as well. This is done by recursing from the target element up to the closest ancestor element that has a resolved begin time (again noting that for an element to have a resolved begin time, all of its ancestors must have resolved begin times). Then, the recursion is "unwound", and for each ancestor in turn (beneath the resolved ancestor) as well as the target element, the following steps are performed:
1. If the element begin time is resolved, seek the document time (forward or back, as needed) to the begin time of the first interval for the target element.
2. Else (if the begin time is not resolved), just resolve the element begin time at the current time on its parent time container (given the current document position). Disregard the sync-base or event base of the element, and do not "back-propagate" any timing logic to resolve the element, but rather treat it as though it were defined with begin="indefinite" and just resolve begin time to the current parent time. This should create an interval and propagate to time dependents.

In the above rules, the following additional constraint must also berespected:

If a begin time to be used as the seek target occurs before the beginning of the parent time container, the seek-to time isclamped to the begin time of the parent time container. This constraint is applied recursively for all ascendant time containers.
If a begin time to be used as the seek target occurs after the end of any ascendant time container's simple duration, then the seek-to time isclamped to the time container simple end time.

This section is informative

Note that the first constraint means that a hyperlink to a child of a timecontainer will never seek to a time earlier than the beginning of the timecontainer. The second constraint implies that a hyperlink to a child thatbegins after the end of the parent simple duration will seek to the end ofthe parent, and proceed from there. While this may produce surprisingresults, it is the most reasonable fallback semantic for what is essentiallyan error in the presentation.

If a seek of the presentation time is required, it may be necessary toseek either forward or backward, depending upon the resolved begin time ofthe element and the presentation current time at the moment of hyperlinktraversal.

After seeking a document forward, the document should be in largely the same state as if the user had allowed the presentation to run normally from the current time until reaching the element begin time (but had otherwise not interacted with the document). One exception relates to event-based timing in the document, and is described below.
Seeking the presentation time forward should also begin any other elements that have resolved begin times between the current time and the seeked-to time. The elements that are begun in this manner may still be active, may be frozen, or may already have ended at the seeked-to time.
If an element begins and ends within the seek interval (between the current time before the hyperlink traversal and the seeked-to time) it logically begins and ends during the seek.
- In this case, the associatedbeginEvent,endEvent and anyrepeatEvent events are not raised.
- Dependent times defined relative to these events will not be resolved as a result of the seek.
- DOM events (in profiles that support a DOM) will not be raised, and script or other listeners associated with these events will not be called.
Any elements currently active at the time of hyperlinking should "fast-forward" over the seek interval. These elements may also be active, frozen or already ended at the seeked-to time.
- If the element ends during the seek interval, anendEvent is raised. The associated time for the event is the document time before the seek.
- If the element repeats within the seek interval, any associatedrepeatEvents are not raised.
Automatic hyperlinks (i.e. those with anactuate value ofonLoad) will not be actuated when they are seeked over during hyperlink traversal (the active duration of the hyperlink begins and ends during the seek interval). However, automatic hyperlinks that are only partially seeked over will be actuated (seeking into the active duration of an automatic hyperlink will actuate the hyperlink). This models the effects of seeking and automatic hyperlinks in the same manner as timing events.

The net effect is that seeking forward to a presentation time puts thedocument into a state largely identical to that as if the documentpresentation time advanced undisturbed to reach the seek time. If thepresentation is authored with nobeginEvent,endEvent orrepeatEvent based timing and noautomatic hyperlinks, then state of the document after a seek should beidentical to that had the document presentation time advanced undisturbed toreach the seeked-to time.

If the resolved activation time for an element that is the target of ahyperlink traversal occurs in the past, the presentation time must seekbackwards. Seeking backwards will rewind any elements active at the time ofhyperlinking.

Just as for forward seeks, elements that begin and end within the seek intervals will not raisebeginEvent,endEvent orrepeatEvent events.
If an element is active at the time of hyperlinking and the element's current interval begins during the seek interval, the element is turned off and anendEvent is raised. The associated time for the event is the document time before the seek. This action does not resolve any times in the instance times list for end times.
If the element repeats within the seek interval, any associatedrepeatEvents are not raised.
Resolved begin times (e.g. a begin associated with an event) are not cleared or lost by seeking to an earlier time. Resolved end times associated with events, Repeat-values, Accesskey-values or added via DOM method calls are cleared when seeking to time earlier than the resolved end time. This follows the semantics for resetting element state.
Seeking to a time before a resolved begin time does not affect the interpretation of arestart="never" setting for an element; once the begin time is resolved, it cannot be changed or restarted.
When the document seeks backwards before a resolved begin for an element time, this does not reset the element.
Once resolved, begin times are not cleared by hyperlinking. However, they may be overwritten by subsequent resolutions driven by multiple occurrences of an event (i.e. by restarting).

This section is informative

These hyperlinking semantics assume that a record is kept of the resolvedbegin time for all elements, and this record is available to be used fordetermining the correct presentation time to seek to. For example:

<smil ...>...<par begin="0">   <img xml:id="A" begin="10s" .../>   <img xml:id="B" begin="A.begin+5s" .../>   <img xml:id="C" begin="B.activateEvent" .../>   <img xml:id="D" begin="C.begin+5s" .../>   ...   <a href="#D">Begin image D</a></par>...</smil>

The begin time of elementsA andB canbe immediately resolved to be at 10 and 15 seconds respectively. The begin ofelementsC andD are unresolved when thedocument starts. Therefore activating the hyperlink will resolve the begin ofD but have no effect upon the presentation time for elementC.

Now, assume thatB is clicked at 25 seconds into thepresentation. The click onB resolves the begin ofC; this in turn resolvesD to begin at 30seconds. From this point on, traversing the hyperlink will cause thepresentation time to be seeked to 30 seconds.

If at 60 seconds into the presentation, the user again clicks onB,D will become re-resolved to apresentation time of 65 seconds. Subsequent activation of the hyperlink whileD is active will result in the seeking the presentation to65 seconds. If the hyperlink is activated whenD is nolonger active, the presentation will seek to the earliest resolved begin timeofD, at 30 seconds.

Implications of beginElement()and hyperlinking forseq andexcl time containers

For a child of a sequence time container, if a hyperlink targeted to thechild is traversed, this seeks the sequence to the beginning of the child.

If the seek is forward in time and the child does not have a resolved begin time, the document time must seek past any scheduled active end on preceding elements, and then activate the referenced child. In such a seek, if the currently active element does not have a resolved active end, it should be ended at the current time. AnendEvent event is raised, with the current time as the associated event time.
If there are other intervening siblings (between the currently playing element and the targeted element), the document time must seek past all scheduled times, and resolve any unresolved times as seek proceeds (time will resolve to intermediate values of "now" as this process proceeds).
As times are resolved, all associated time dependents get notified. Note however, that since no events are raised for elements that begin and end (or repeat) within the seek interval, time dependents defined relative to these events will not be notified and dependent times will not be resolved.
WhenbeginElement() orbeginElementAt() is called for the child of a sequence time container (subject to restart semantics), any currently active or frozen child is stopped and the new child is begun at the current time (even if the element has a scheduled begin time). Unlike hyperlinking, no seek is performed. The sequence will play normally following the child that is begun with the method call (i.e. as though the child had begun at its normal time).
Note that the presentation agent need not actually prepare any media for elements that are seeked over, but it does need to propagate the sync behavior to all time dependents so that the effect of the seek is correct.

This section is informative

Note that if a hyperlink targets (or ifbeginElement() orbeginElementAt() is called for) an elementAdefined to begin when another elementB ends, and the otherelementB has (e.g.) an event-base or syncbase end, thehyperlink or method call will not end elementB. It willonly activate elementA. If the two elements are siblingswithin aseq orexcl time container, the parent timecontainer enforces its semantics and stops (or pauses) the runningelement.

If a hyperlink targets a child of anexcl time container, activating the link willseek to the earliest computed begin. This means that pause/defer stacksemantics do not need to be accounted for when linking to an element. Insteadthe document timeline will simply be seeked to the first resolved time forthe element, or seeked to the start of the time container and the targetelement simply started if there is no resolved begin time.

Propagating changes to times

This section is informative

There are several cases in which times may change as the document ispresented. In particular, when an element time is defined relative to anevent, the time (i.e. the element begin or active end) is resolved when theevent occurs. Another case arises with restart behavior - the element gets anew begin and active end time when it restarts. Since the begin and activeend times of one element may be defined relative to the begin or active endof other elements, any changes to times must be propagated throughout thedocument.

When an element "foo" has a begin or active end time that specifies asyncbase element (e.g. "bar" as below):

<img xml:id="foo" begin="bar.end" .../>

we say that "foo" is atime-dependent of "bar" - that is, the"foo" begin time depends upon the active end of "bar". Any changes to theactive end time of "bar" must be propagated to the begin of "foo" so that"foo" begins properly when "bar" ends. The effect on "foo" of the propagatedchange depends upon the state of "foo" when the change happens.

If an element begin time or end time changes, this change must be propagated to any other elements that are defined relative to the changed time (i.e. to all time dependents). More specifically, when the begin or end of the current interval for an element changes, it must propagate the change to all dependent instance times. If the dependent element current interval begin or end times change as a result, these changes must in turn also be propagated. For details, seeEvaluation of begin and end time lists.
If an element ends later than its specified end time (e.g. if a negative offset is specified with a user event), the propagated time must be the computed time and not the observed time.
If an element ends earlier than its specified end time (e.g. if a parent time container constraint cuts short the element, or a DOM method call ends the element), the propagated time must be the constrained time.

Deferred elements and propagatingchanges to begin

This section is informative.

One exception to normal processing is made for elements that aredeferred according toexclinterrupt semantics. This exception is made to simplify the model: once anelement is deferred, it will stop normal handling of time change notices thatare propagated to the element begin conditions, as time dependents ofsyncbase elements. That is, with respect to the behavior of the element as atime dependent, the element behaves as though it had already begun. Thisexception is made so that the deferred element cannot change its begin timedue to syncbase element changes, while it is deferred. In effect, the elementshould have begun at the time it was deferred, and so it should nolonger handle changed time notices.

Restart and propagating changes to times

This section is informative

In some cases, the semantics of restart may preclude the correctpropagation of changes to time, as in the following example:

<smil ...>...<par>   <img xml:id="img1" dur="10s" end="activateEvent" .../>   <video begin="img1.end-3s" restart="whenNotActive" .../></par>...</smil>

If the user clicks the image at 8 seconds, the image will end at thatpoint, and the changed end time will propagate to the video. However, thevideo will have begun at 7 seconds (3 seconds before the calculated end of 10seconds), and cannot restart. The propagated change will be ignored. See alsoInteraction with restart semantics inthe section onEvaluation ofbegin and end time lists.

Time container duration

This section is informative

The implicit duration of a time container is defined in terms of thechildren of the container. The children can be thought of as the "media" thatis "played" by the time container element. The semantics are specific to eachof the defined time container variants, and are described in the respectivesections: Thepar element, theseq element, and theexcl element.

Note that the term "computed values" should not be confused with thevalues of times that are dynamic within the time graph. In the followingexample, the video will be cut short if the user activates (e.g., clicks on)it before 10 seconds. If the user does not click, thepar has a simple duration of 10 seconds. Ifthe user activates the video at 5 seconds, thepar has a simple duration of 8 seconds.Although the original end time for the video could be computed by animplementation as 10 seconds, the endsync semantics must be evaluated withthe updated times that account for the user events.

<smil ...>...<par endsync="last" >   <audio dur="8s" .../>   <video begin="0" dur="10s" end="click" .../></par>...</smil>

Time containerconstraints on child durations

Time containers place certain overriding constraintsupon the child elements. These constraints may cut short the active durationof any child element.

All time containers share the basic overriding constraint:

A child element may not be active before the beginning, nor after the end of either the parent simple duration or parent active duration.
Note the time container is itself subject to the same constraints, and so may be cut short by some ascendant time container. When this happens, the children of the time container are also cut off, in the same manner as for the last partial repeat in the example below.

This section is informative

While the child may define a sync relationship that places the beginbefore the parent begin, the child is not active until the parent begins.This is equivalent to the semantic described inNegative begin delays.

If the child defines an active duration (or by the same token a simpleduration) that extends beyond the end of the parent simple duration, theactive duration of the child will be cut short when the parent simpleduration ends. Note that this does not imply that the child duration isautomatically shortened, or that the parent simple duration is "inherited" bythe child.

For example:

<par dur="10s" repeatDur="25s">   <video dur="6s" repeatCount="2" .../>   <text xml:id="text1" begin="5s" dur="indefinite" .../>   <audio begin="text1.end" .../></par>

The video will play once for 6 seconds, and then a second time but onlyfor 4 seconds - the last 2 seconds will get cut short and will not be seen.The text shows up for the last 5 seconds of thepar, and the indefinite duration is cut shortat the end of the simple duration of thepar. The audio will not show up at all, sinceit is defined to begin at the end of the active duration of the previouselement (thetext element). Since thetext element ends when the time container ends, the audio would begin afterthe time container has ended, and so never is heard. When thepar repeats the first time, everythinghappens just as it did the first time. However the last repeat is only apartial repeat (5 seconds), and so only the video will be seen, but it willnot be seen to repeat, and the last second of the video will be cut off.

In addition,excl time containersallow only one child to play at once. Subject to thepriorityClass semantics, the activeduration of an element may be cut short when another element in the timecontainer begins.

The min attribute and time container constraintson child durations

This section is informative.

The fill attribute is also used to extend the active duration if it isless than the duration specified in the min attribute.

<par dur="5s">   <img xml:id="img" min="7s" dur="4s" fill="freeze".../> </par>

Time container constraints onsync-arcs and events

This section is informative

SMIL 1.0 defined constraints on sync-arc definition(e.g., begin="id(image1)(begin)"), allowingreferences only to qualified siblings. SMIL 2.0 explicitly removes thisconstraint. SMIL 2.0 also adds event-based timing. Both sync-arcs andevent-timing are constrained by the parent time container of the associatedelement as described above.

Specifics for sync-arcs

While a sync-arc is explicitly defined relative to a particular element,if this element is not a sibling element, then the sync is resolved as async-relationshipto the parent (i.e. to an offset from the parentbegin).

If the defined sync would place the resolved element begin before the parent time container begin, part of the element will simply be cut off when it first plays. This is like the behavior obtained using clipBegin.
However unlike with clipBegin, if the sync-arc defined child element also has repeat specified, only the first iteration will be cut off, and subsequent repeat iterations will play normally. See alsoNegative begin delays.

This section is informative

Note that in particular, an element defined with a sync-arc begin will notautomatically force the parent or any ancestor time container to begin.

For the case that an element with a sync-arc is in a parent (or ancestor)time container that repeats: for each iteration of the parent or ancestor,the element is played as though it were the first time the parent timelinewas playing. With each repeat of the parent, the sync-arc will berecalculated to yield a begin time relative to the parent time container. Seealso the sectionResetting elementstate.

Specifics for event-based timing

This section is informative

The specifics for event-based timing are discussed intheEvent Sensitivity section.

Behavior of 0 duration elements

Media elements with an active duration of zero or with the same begin and end time trigger begin and end events, and propagate to time dependents. If an element's end time is before its begin time, no events are triggered (see alsoEvaluation of begin and end time lists).

Whether or not media with zero duration and no fill period is retrievedand/or briefly rendered is implementation dependent.

5.4.6 Clarifications and surprisingresults

This section is informative

When an element begins, any event-based begin times are cleared. In thefollowing example, if an activate event occurs and then one second later barends, then foo begins immediately and the element does not restart fourseconds later regardless of therestart setting. However, if an activateevent occurs and bar does not end during the next five seconds, the elementwill restart at the end of that time.

<audio xml:id="foo" begin="bar.end; activateEvent+5s".../>

See Evaluation of begin and end time lists.

`DOMString`	`typeArg`	Specifies the event type.
`views::AbstractView`	`viewArg`	Specifies the`Event`'s`AbstractView`.
`long`	`detailArg`	Specifies the`Event`'s detail.

Movatterモバイル変換

5. SMIL 3.0 Timing and Synchronization

Table of contents

5.1Overview and Summary of Changesfor SMIL 3.0

Thebeginanddur attributes: basic timingsupport

Theendattribute: controlling active duration

Themin and maxattributes: more control over the active duration

Themin attribute and negative begin times

Theendsync attribute

TherepeatCount,repeatDur, andrepeat attributes: repeating elements

Theminattribute and restart:

Thefillattribute: extending an element

ThefillDefault attribute

The Event sensitivity andfill

Therestart attribute

ThesyncBehavior,syncTolerance, andsyncMaster attributes: controllingruntime synchronization

Theparelement

Implicit duration ofpar

Theseqelement

Implicit duration ofseq containers

Theexclelement

Implicit duration ofexcl containers

ThepriorityClass element

Examples usingexcl andpriorityClass

Scheduled begin times andexcl

Handling SimultaneousBegins withinexcl

TherepeatCount and unresolved simpleduration

Implications of beginElement()and hyperlinking forseq andexcl time containers

Deferred elements and propagatingchanges to begin

Themin attribute and time container constraintson child durations

The beginanddur attributes: basic timingsupport

The endattribute: controlling active duration

The min and maxattributes: more control over the active duration

The min attribute and negative begin times

The endsync attribute

The repeatCount,repeatDur, andrepeat attributes: repeating elements

The minattribute and restart:

The fillattribute: extending an element

The fillDefault attribute

The restart attribute

The syncBehavior,syncTolerance, andsyncMaster attributes: controllingruntime synchronization

The parelement

The seqelement

The exclelement

The priorityClass element

The repeatCount and unresolved simpleduration

The min attribute and time container constraintson child durations