This section is informative
The SMIL 2.1 specification leaves the basic syntax and semantics of theSMIL 2.0 timing model unchanged[SMIL20-timing]. The only changes for SMIL2.1 are that SMIL 2.0's ExclTimeContainers module is deprecated and replacedwith two new modules:BasicExclTimeContainers andBasicPriorityClassContainers, an errata notehas been integrated into the specification that clarifies the default eventbase for animation elements, and a fix for a text error in thefourth bullet of the
As a result of this change, SMIL 2.1 Timing and Synchronization support isbroken down into 16 modules instead of the 15 modules used in SMIL 2.0. Thesemodules are described inAppendix A: SMILTiming and Synchronization modules.
This section is informative
SMIL 1.0 solved fundamental media synchronization problemsand defined a powerful way of choreographing multimedia content. SMIL 2.1extends the timing and synchronization support, adding capabilities to thetiming model and associated syntax. Some SMIL 1.0 syntax has been changed ordeprecated. This section of the document specifies the Timing andSynchronization module.
There are two intended audiences for this module: implementers of SMIL 2.1document viewers or authoring tools, and authors of other XML languages whowish to integrate timing and synchronization support. A language with whichthis module is integrated is referred to as ahost language. Adocument containing SMIL Timing and Synchronization elements and attributesis referred to as ahost document.
As this module is used in different profiles (i.e. host languages), theassociated syntax requirements may vary. Differences in syntax should beminimized as much as is practical.
SMIL 2.1 Timing and Synchronization support is broken down into 16modules, allowing broad flexibility for language designers integrating thisfunctionality. These modules are described inAppendix A: SMIL Timing and Synchronizationmodules.
This section is informative
SMIL Timing defines elements and attributes to coordinate and synchronizethe presentation ofmedia over time. The termmedia coversa broad range, includingdiscrete media types such as still images,text, and vector graphics, as well ascontinuous media types thatare intrinsically time-based, such as video, audio and animation.
Three synchronization elements support common timing use-cases:
These elements are referred to astime containers. They grouptheir contained children together into coordinated timelines.
SMIL Timing also provides attributes that can be used to specify anelement's timing behavior. Elements have a begin, and asimpleduration. The begin can be specified in various ways - for example, anelement can begin at a given time, or based upon when another element begins,or when some event (such as a mouse click) happens. Thesimpleduration defines the basic presentation duration of an element. Elementscan be defined to repeat the simple duration, a number of times or for anamount of time. The simple duration and any effects of repeat are combined todefine theactive duration. When an element's active duration hasended, the element can either be removed from the presentation orfrozen(held in its final state), e.g. to fill any gaps in the presentation.
An elementbecomes active when it begins its active duration, andbecomes inactive when it ends its active duration. Within the activeduration, the element isactive, and outside the active duration,the element isinactive.
Figure 1 illustrates the basic support of a repeating element within asimple<par> time container. Thecorresponding syntax is included with the diagram.
<par begin="0s" dur="33s"> <video begin="1s" dur="10s" repeatCount="2.5" fill="freeze" .../></par>
Figure 1 - Strip diagram of basic timing support. The starred"Simple*" duration indicates that the simple duration is partial (i.e. it iscut off early).
The attributes that control these aspects of timing can be applied notonly to media elements, but to the time containers as well. This allows, forexample, an entire sequence to be repeated, and to be coordinated as a unitwith other media and time containers. While authors can specify a particularsimple duration for a time container, it is often easier to leave theduration unspecified, in which case the simple duration is defined by thecontained child elements. When an element does not specify a simple duration,the time model defines animplicit simple duration for the element.For example, the implicit simple duration of a sequence is based upon the sumof the active durations of all the children.
Each time container also imposes certaindefaults andconstraints upon the contained children. For example in a
<par begin="0s" dur="12s" repeatDur="33s" fill="freeze" > <video begin="1s" dur="5s" repeatCount="1.8" fill="freeze" .../></par>
Figure 2 - Strip diagram of time container constraints upon childelements. The starred "Simple*" durations indicate that the simple durationis partial (i.e. it is cut off early).
The SMILTiming Model defines how the time container elements andtiming attributes are interpreted to construct atime graph. Thetime graph is a model of the presentation schedule andsynchronization relationships. The time graph is a dynamic structure,changing to reflect the effect of user events, media delivery, and DOMcontrol of the presentation. At any given instant, the time graph models thedocument at that instant, and the semantics described in this module.However, as user events or other factors cause changes to elements, thesemantic rules are re-evaluated to yield an updated time graph.
When abegin orend value refers to an event, or to the begin or active end of anotherelement, it may not be possible to calculate the time value. For example, ifan element is defined to begin on some event, the begin time will not beknown until the event happens. Begin and end values like this are describedasunresolved. When such a time becomes known (i.e. when it can becalculated as a presentation time), the time is said to beresolved.A resolved time is said to bedefinite if it is not the value"indefinite". See also the discussion ofUnifying scheduled and interactivetiming.
In an ideal environment, the presentation would perform precisely asspecified. However, various real-world limitations (such as network delays)can influence the actual playback of media. How the presentation applicationadapts and manages the presentation in response to media playback problems istermedruntime synchronization behavior. SMIL includes attributesthat allow the author to control the runtime synchronization behavior for apresentation.
This section is informative
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 are presented.
The time model depends upon several definitions for the host document: Ahost document is presented over a certain time interval.
This section defines the set of timing attributes that are common to allof the SMIL synchronization elements.
Unless otherwise specified below, if there is any error in the argumentvalue syntax for an attribute, the attribute will be ignored (as though itwere not specified).
This section is informative
The basic timing for an element is described using the
This section is normative
This section is normative
id(Id-value)(begin) is equivalent toId-value.begin id(Id-value)(end) is equivalent toId-value.endid(Id-value)(Clock-value) is equivalent toId-value.begin+ Clock-valueThis section is informative
Children of apar begin by defaultwhen thepar begins (equivalent tobegin="0s"). Children of abegin="0s"); the firstchild begins by default when the parent
Thebegin value can 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 canalso 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 the
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 valuesforbegin, "indefinite" is only reallyuseful as a single value. Combining it with other values does not impactbegin timing, as DOM begin methods can 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.
This section is informative
The use of negative offsets to define begin times merely defines thesynchronization relationship of the element. It does not in any way overridethe time container constraints upon the element, and it cannot override theconstraints of presentation time.
This section is normative
The computed begin time defines thescheduledsynchronization relationship of the element, even if it is not possibleto begin the element at the computed time. The time model uses the computedbegin time, and not the observed time of the element begin.
This section is informative
If an element has a begin time that resolves toa time before the parent time container begins, the parent time containerconstraint still applies. For example:
<par> <video begin="-5s" dur="10s" src="movie.mpg" /> <audio begin="vid.begin+2s" dur="8s" src="sound.au" /></par>
Thevideoelement cannot begin before theparbegins. The begin is simply defined to occur"in the past" when thepar begins. The viewer will observe thatthe video begins 5 seconds into the media, and ends after 5 seconds. Notethat the audio element begins relative to the video begin, and that thecomputed begin time is used, and not the observed begin time as constrainedby the parent. Thus the audio begins 3 seconds into the media, and also lasts5 seconds.
The behavior can be thought of as a
This section is normative
The behavior can be thought of as a
The element will actually begin at the timecomputed according to the following 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 therepeat event has the calculated value based upon the abovecomputed begin time, and not the observed number of repeats.
This section isinformative
Thus for example:
<smil ...> ...<ref begin="foo.activateEvent-8s" dur="3s" repeatCount="10" .../>...</smil>
The element begins when the user activates (forexample, clicks on) the element "foo". Its calculated begin time is actually8 seconds earlier, and so it begins to play at 2 seconds into the 3 secondsimple duration, on the third repeat iteration. One second later, the fourthiteration of the element will begin, and the associatedrepeatevent will have the iteration value set to 3 (since it is zero based). Theelement will end 22 seconds after the activation. ThebeginEventevent is raised when the element begins, but has a time stamp value thatcorresponds to the defined begin time, 8 seconds earlier. Any time dependentsare activated relative to the computed begin time, and not the observed begintime.
Note: If script authors wish to distinguishbetween the computed repeat iterations and observed repeat iterations, theycan count actualrepeat events in the associated eventhandler.
A begin time specifies a synchronizationrelationship between the element and the parent time container. Syncbasevariants, eventbase, marker and wallclock timing are implicitly converted toan offset on the parent time container, just as an offset value specifiesthis directly.For children of a
Note that an element cannot actually begin until the parent time containerbegins. An element with a negative time delay behaves as if it had begunearlier.The presentation effect for theelement (e.g. the display of visual media) is equivalent to that for a
The length of the simple duration is specifiedusing thedur attribute. Thedur attributesyntax is described below.
This section is normative
If there is any error in the argument value syntax fordur, the attribute will be ignored (asthough it were not specified).
If the "media" attribute value is used onan element that does not define media (e.g. on the SMIL 2.1 time containerelementspar,seq and
If the element does not have a (valid)
If the author specifies a value for
If the author specifies a simple duration that islonger than the implicit duration for an element, the implicitduration of the element is extended to the specified simple duration:
Note that when the simple duration is "indefinite",some simple use cases can yield surprising results. See the related example #4 in Appendix B.
The following example shows simple offset begintiming. The<audio>elementbegins 5 seconds after the<par>time container begins, and ends 4 seconds later.
<par> <audio src="song1.au" begin="5s" dur="4s" /></par>
The following example shows syncbase begintiming. The<img> element begins 2seconds after the<audio>element begins.
<par> <audio src="song1.au" /> <img src="img1.jpg" begin="song1.begin+2s" /></par>
Elements can also be specified to begin inresponse to an event. In this example, the image element begins (appears)when the user clicks on element "show". The image will end (disappear) 3 anda half seconds later.
<smil ...>...<text ... /><img begin="show.activateEvent" dur="3.5s" ... />...</smil ...>
This section is informative
SMIL 2.1 provides an additional control over theactive duration. Theend attributeallows the author to constrain the active duration by specifying an end valueusing a simple offset, a time base, an event-base, a syncbase, or DOM methodscalls. The rules for combining the attributes to compute the active durationare presented in the section,Computingthe active duration.
The normative syntax rules for each attribute valuevariant are described in the sectionTiming attribute value grammars; asyntax summary is provided here as an aid to the reader.
This section is normative
endElement() method call.If anendattribute is specified but none of
If the
The deprecatedSMIL1.0-syncbase-values are semantically equivalent to the following SMIL 2.1end-value types:
id(Id-value)(begin) is equivalent toId-value.begin id(Id-value)(end) is equivalent toId-value.endid(Id-value)(Clock-value) is equivalent toId-value.begin+Clock-valueThis section isinformative
The end value can specify a list of times. This can beused to specify multiple "ways" or "rules" to end an element, e.g. if any oneof several events is raised. A list of times can also define multiple endtimes that can correspond to multiple begin times, allowing the element toplay more than once (this behavior can be controlled - see also the
In the following example, the
<video end="10s" src="8-SecondVideo.mpg" .../>If an author wishes to specify the implicit duration as well as an endconstraint, thedur attribute can bespecified as "media". In the following example, the element willend at the earlier of the intrinsic media duration, or a mouse click:
<html ...>...<video dur="media" end="click" src="movie.mpg" .../>...</html>
These cases arise from the use of negativeoffsets in the sync-base and event-base forms, and authors should be aware ofthe complexities this can introduce. See alsoHandling negative offsets for end
In the following example, the active durationwill end at the earlier of 10 seconds, or the end of the "foo" element. Thisis particularly useful if "foo" is defined to begin or end relative to anevent.
<audio src="foo.au" dur="2s" repeatDur="10s" end="foo.end" .../>
In the following example, the active durationwill end at 10 seconds, and will cut short the simple duration defined to be20 seconds. The effect is that only the first half of the element is actuallyplayed. For a simple media element, the author could just specify this usingthe dur attribute. However in other cases, it is sometimes important tospecify the simple duration independent of the active duration.
<par> <audio src="music.au" dur="20s"end="10s" ... /></par>
In the following example, the element beginswhen the user activates (e.g., clicks on) the "gobtn" element. The activeduration will end 30 seconds after the parent time containerbegins.
<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 thetarget element before 30 seconds elapse, the element will never begin. Inthis case, the element has no active duration and no active end.
The defaults for the event syntax make it easyto define simple interactive behavior. The following example stops the imagewhen the user clicks on the element.
<html ...>...<img src="image.jpg"end="click" />...</html>
Usingendwith an event value enables authors to end an element based on either aninteractive event or a maximum active duration. This is sometimes known aslazy interaction.
In this example, a presentation describesfactory processes. Each step is a video, and set to repeat 3 times to makethe point clear. Each element can also be ended by clicking on the video, oron some element "next" that indicates to the user that the next step shouldbe 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 isdefined to be the earlier of 15 (5s dur * 3 repeats) seconds after it begins,or a click on "next". This lets the viewer sit back and watch, or advance thepresentation at a faster pace.
This section is normative
This section is informative
The min/max attributes provide the author with a way to control the lowerand upper bound of the element active duration.
This section is normative
If there is any error in the argument value syntax formin, the attribute will be ignored (asthough it were not specified).
The default value for
If there is any error in the argument value syntax formax, the attribute will be ignored (asthough it were not specified).
The default value for
If the "media" argument value is specifiedfor eithermin or
If bothmin andmax attributes are specified then themax value must be greater than or equalto themin value. If this requirement isnot fulfilled then both attributes are ignored.
The rule to apply to compute the active duration of anelement withmin or
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 for
Example 1. In the following example, the video will only play for 10seconds.
<smil ...>...<par > <videomax="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 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 an
<smil ...>...<par end="foo.activateEvent"min="12s" > <video .../> <video .../></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 the
<html ...>...<par endsync="first" min="12s" fill="freeze" > <video end="click" ...> <video .../></par>...</html>
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 of"remove",nothing is shown for the time container between 5 seconds and 12 seconds.
<par dur="5s" min="12s" > <video/> <video /></par>
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 the
Example 1. In the following example, the image will be displayed from thebeginning of the time container for 2 seconds.
<par> <img begin="-5s" min="7s" dur="5s" .../></par>
Example 2. In the following example, the image will not be displayed atall.
<par> <img begin="-5s" min="4s" dur="2s" .../></par>
See also the sectionsThe min attributeand restart andTime containerconstraints on child durations.
This section isnormative
The syntax specifications are defined using EBNF notation as defined inXML 1.1[XML11]
In the syntax specifications that follow, allowedwhite space is indicated as "S", defined as follows (taken from the[XML11]definition for 'S'):
S ::= (#x20 | #x9 | #xD | #xA)+This section isnormative
A begin-value-list is a semi-colon separated listof timing specifiers:
begin-value-list ::= begin-value (S? ";"S? begin-value-list )?begin-value ::= (offset-value | syncbase-value | event-value| repeat-value | accesskey-value | media-marker-value | wallclock-sync-value | "indefinite" )
This section isnormative
An end-value-list is a semi-colon separated listof timing specifiers:
end-value-list ::= end-value (S? ";"S? end-value-list )?end-value ::= (offset-value | syncbase-value | event-value | repeat-value | accesskey-value | media-marker-value | wallclock-sync-value | "indefinite" )
Several of the timing specification values havea similar syntax. To parse an individual itemin a value-list, the following approach defines the correctinterpretation. In addition,Id-values andEvent-symbols are XML NMTOKEN values andas such are allowed to contain the full stop '.' andhyphen-minus '-' characters.The reversesolidus character '\' must be used to escape these characters withinId-valuesandEvent-symbols
'+' or'-'), the value should be parsed as anoffset value..' characters preceded by a reverse solidus '\' escape character should not be treated as a separator, but as a normal token character..' separator character, then the value should be parsed as anevent-value with an unspecified (i.e. default) eventbase-element..begin" or ".end", then the value should be parsed as asyncbase-value..marker(", then the value should be parsed as amedia-marker-value.This approach allows implementations to treat thetokenswallclock andindefinite as reserved element IDs, and
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 numberMinutes ::= 2DIGIT; range from 00 to 59Seconds ::= 2DIGIT; range from 00 to 59Fraction ::= DIGIT+Timecount ::= DIGIT+2DIGIT ::= DIGIT DIGITDIGIT ::= [0-9]
For Timecount values, the default metric suffix is"s" (for seconds).No embedded white spaceis allowed in clock values, although leading and trailing white spacecharacters will be ignored.
The following are examples of legal clockvalues:
02:30:03 50:00:10.25= 50 hours, 10 seconds and 250 milliseconds
02:33 00:10.5= 10.5 seconds = 10 seconds and 500 milliseconds 3.2h = 3.2 hours = 3 hours and 12 minutes 45min = 45 minutes 30s = 30 seconds 5ms = 5 milliseconds 12.467 = 12 seconds and 467 millisecondsFractional values are just (base 10) floatingpoint definitions of seconds. The number of digits allowed is unlimited(although actual precision may vary among implementations).
For example:
00.5s = 500 milliseconds00:00.005 = 5 milliseconds
Offset values are used to specify when an elementshould begin or end relative to its syncbase.
This section isnormative
An offset value has the followingsyntax:
offset-value ::= (S? ("+" | "-")S? )? ( Clock-value )The implicit syncbase for an offset value isdependent upon the time container:
Deprecated.
smil-1-syncbase-value ::= "id(" Id-value ")" ( "(" ( "begin" | "end" | Clock-value) ")" )?
This section isnormative
ID reference values are references to the value ofan "id" attribute of another element in the document.
Id-value ::= Id-ref-valueId-ref-value ::= IDREF | Escaped-Id-ref-valueEscaped-Id-ref-value ::= Escape-Char NMTOKENEscape-Char ::= "\"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 isinformative
The semantics of ignored elements may change in a future version of SMIL.One possible semantic is that the associated sync arc arguments will not beinvalid, but will instead always be "unresolved". When this behavior needs tobe simulated in this version of SMIL Timing and Synchronization, an authorcan include the value "indefinite" in the list of values for the begin or endattribute.
A syncbase value starts with a Syncbase-elementterm defining the value of an "id" attribute of another element referred toas the syncbase element.
This section isnormative
A syncbase value has the followingsyntax:
Syncbase-value ::= ( Syncbase-element"." Time-symbol )
(S? ("+"|"-")S? Clock-value )?
Syncbase-element ::= Id-value
Time-symbol ::= "begin" | "end"
The syncbase element is qualified with one of thefollowingtime symbols:
Examples
begin="x.end-5s" :Begin 5 seconds before "x" ends begin=" x.begin " : Begin when "x" begins end="x.begin + 1min" : End 1 minute after "x"begins
This section isinformative
An Event value starts with an Eventbase-elementterm that specifies theevent-base element. The event-base elementis the element 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 can be observed. Refer toDOM-Level2-Events[DOM2Events] for details.
This section isnormative
An event value has the following syntax:
Event-value ::= (Eventbase-element "." )? Event-symbol
(S? ("+"|"-")S? Clock-value )?
Eventbase-element ::= ID
The eventbase-element must be another elementcontained in the host document.
If the Eventbase-element term is missing, theevent-base element defaults to the element on which the eventbase timing isspecified (the current element). A host language designer may override thedefinition of the default eventbase element. As an example of this, theSMIL 2.1Animation modules describe Timing integration requirements forthe animation elements (animate, animateMotion, etc.). These requirementsspecify that the default eventbase element is the target element of theanimation. SeeSMIL2 Animation section 3.9.1 (Integration requirements).
The event value must specify an Event-symbol.This term is an XML NMTOKEN that specifiesthe name of the event that is raised on the Event-base element.
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 isan offset from the time of the event.
This section is informative
This module defines several events that may beincluded in the supported set for a host language, includingbeginEvent andendEvent. These should not beconfused with the syncbase time values. See the section on Events and event model.
The semantics of event-basedtiming are detailed inUnifyingScheduling and Interactive Timing. Constraints on event sensitivity aredetailed in Eventsensitivity.
Examples:
begin=" x.load " :Begin when "load" is observed on "x" begin="x.focus+3s" : Begin 3 seconds after a "focus"event on "x" begin="x.endEvent+1.5s": Begin 1 and a half seconds after an"endEvent" event on "x" begin="x.repeat" : Begin each time arepeat event is observed on "x"
The following example describes a qualifiedrepeat eventbase value:
<html ...>...<video repeatCount="10" end="endVideo.click" ... /><imgbegin="foo.repeat(2)" .../>...</html>
The "endVideo" image will appear when the video"foo" repeats the second time. This example allows the user to stop the videoafter it has played though at least twice.
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 willonly be resolved when a repeat is observed that has a iteration value thatmatches the specified iteration.
The qualified repeat event syntax allows an author torespond only to an individual repeat of an element.
Accesskey values allow an author to tie a begin or end time to aparticular key press, independent of focus issues. It is modeled on the HTMLaccesskey support. Unlike with HTML, user agents should not require that amodifier key (such as "ALT") be required to activate an access key.
An access key value has the followingsyntax:
Accesskey-value ::= "accesskey(" character")" The character is a single character from[ISO10646].
(S? ("+"|"-")S? Clock-value )?
The time value is defined as the time that theaccess key character is input by the user.
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.
This section is normative
Media-Marker-value ::= Id-value ".marker("S? marker-name S? ")"
This section is informative
Wallclock-sync values have the following syntax.The values allowed are based upon several of the "profiles" described in[DATETIME], which is based upon[ISO8601].
This section is normative
wallclock-sync-value ::= "wallclock("S? (DateTime | WallTime | Date)S? ")"DateTime ::= Date "T" 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 12Days ::= 2DIGIT; range from 01 to 31Hours24 ::= 2DIGIT; range from 00 to 234DIGIT ::= DIGIT DIGIT DIGIT DIGITTZD ::= "Z" | (("+" | "-") Hours24 ":" Minutes )
This section isinformative
Complete date plus hours and minutes: YYYY-MM-DDThh:mmTZD (e.g. 1997-07-16T19:20+01:00)Complete date plus hours, minutes and seconds: YYYY-MM-DDThh:mm:ssTZD (e.g. 1997-07-16T19:20:30+01:00)Complete date plus hours, minutes, seconds and a decimal fraction of a second YYYY-MM-DDThh:mm:ss.sTZD (e.g. 1997-07-16T19:20:30.45+01:00)
Note that the Minutes, Seconds, Fraction, 2DIGITand DIGIT syntax is as defined forClock-values. Note that white space isnot allowed within the date and time specification.
This section is normative
There are three ways of handling time zoneoffsets:
The presentation engine must be able to convertwallclock-values to a time within the document.
This section isinformative
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 the
The following examples all specify a begin atmidnight on January 1st 2000, UTC:
begin="wallclock( 2000-01-01T00:00Z )"begin="wallclock( 2000-01-01T00:00:00Z )"begin="wallclock( 2000-01-01T00:00:00.0Z )"begin="wallclock( 2000-01-01T00:00:00.0Z )"begin="wallclock( 2000-01-01T00:00:00.0-00:00 )"
The following example specifies a begin at 3:30in the afternoon on July 28th 1990, in the Pacific US time zone:
begin="wallclock( 1990-07-28T15:30-08:00 )"The following example specifies a begin at 8 inthe morning wherever the document is presented:
begin="wallclock( 08:00 )"This section is normative
The
Semantics of
Semantics of
Semantics of
pause() 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. 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 of
This section is n
The following pseudo-code describes the
//// 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()
This section is informative
SMIL 1.0 introduced the repeat attribute, whichis used to repeat a media element or an entire time container. SMIL 2.1introduces two new controls for repeat functionality that supercede the SMIL1.0repeat attribute. The newattributes,repeatCount andrepeatDur, provide a semantic thatmore closely 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" several times in sequence. This will effectively copy orloop the contents of the element media (or an entire timeline in thecase of a time container). The author can specify eitherhow many timesto repeat, using
In the following example, the implicit durationof the audio is constrained by
<audio src="3second_sound.au"repeatCount="0.5" />In this example, the 3 second (implicit) simpleduration will be played three times through and then is constrained by thedurattribute on the parentpar
<par dur="9s"> <audio src="3second_sound.au" repeatCount="100" /></par>In the following example, the 2.5 second simpleduration will be repeated twice; the active duration will be 5seconds.
<audio src="background.au" dur="2.5s" repeatCount="2" />In the following example, the 3 second(implicit) simple duration will be repeated two full times and then the firsthalf is repeated once more; the active duration will be 7.5seconds.
<audio src="3second_sound.au"repeatCount="2.5" />In the following example, the audio will repeatfor a total of 7 seconds. It will play fully two times, followed by afractional part of 2 seconds. This is equivalent to a
<audio src="music.mp3" dur="2.5s"repeatDur="7s" />Note that if the simple duration is indefinite,repeat behavior is not defined (but
<img src="foo.jpg"repeatCount="2" /><img src="bar.png" dur="indefinite"repeatCount="2" />
In the following example, the simple duration is0 for the image and indefinite for the text element, and so repeat behavioris not meaningful. The active duration is 0 for the first element, howeverfor the second element, the active duration is determined by the
<img src="foo.jpg"repeatDur="10s" /><text src="intro.html" dur="indefinite"repeatDur="10s" />
In the following example, if the audio media islonger than the 5 second
<audio src="8second_sound.au"repeatDur="5s" />The
<seq begin="5s"repeatCount="3" > <img src="img1.jpg" dur="5s" /> <img src="img2.jpg" dur="4s" /> <img src="img3.jpg" dur="4s" /></seq>
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 begin="user.activateEvent" min="7s" dur="5s" restart="always" fill="freeze".../></par>...</smil>
The SMIL 1.0 repeat attribute behaves in a mannersimilar to repeatCount, but it defines the functionality in terms of asequence that contains the specified number ofcopiesof the elementwithout the repeat attribute. This definition has caused some confusionamong authors and implementers. See also the SMIL 1.0 specification[SMIL10].
In particular, there has been confusion concerning thebehavior of the SMIL 1.0end attributewhen used in conjunction with the
This section is normative
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 can be used to fill gaps in a presentation, or to extend anelement as context in the presentation (e.g. with additive animation - see[SMIL-ANIMATION]).
This section is normative
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".
The syntax of the fill attribute is the same asin SMIL 1.0, with two extensions. In addition, the fill attribute may now beapplied to any timed element, including time containers.
Note that given the default values for
An element with"freeze"behavior is extended according to the parent time container:
When applied to media,
This section is normative
The effects of the
This section is informative
Thefillattribute can be used to maintain the value of a media element after theactive duration of the element ends:
<par endsync="last"> <video src="intro.mpg" begin= "5s" dur="30s"fill="freeze" /> <audio src="intro.au" begin= "2s" dur="40s"/></par>
The video element ends 35 seconds after theparent time container began, but the video frame at 30 seconds into the mediaremains displayed until the audio element ends. The attribute "freezes" thelast value of the element for the remainder of the time container's simpleduration.
This functionality is also useful to keep priorelements on the screen while the next item of a
<seq> <video fill="freeze" src.../> <video begin="2s" src.../></seq>
The first video is displayed and then the lastframe is frozen for 2 seconds, until the next element begins. Note that if ittakes additional time to download or buffer video "v2" for playback, thefirst video "v1" will remain frozen until video "v2" actuallybegins.
This section is informative
Note that there are severalways that an element may be restarted. The behavior (i.e. to restart or not)in all cases is controlled by the
As with any begin time, if an element is scheduled torestart after the end of the parent time container simple duration, theelement will not restart.
restart =
TherestartDefaultattribute can be used to control the default behavior of the
For details on when and how the
This section is informative
A common use-case requires that the same UIevent is used to begin an element and to end the active duration of theelement. This is sometimes described as "toggle" activation, because the UIevent toggles the element "on" and "off". The
<smil ...>...<imgbegin="bar.activateEvent"end="bar.activateEvent"restart="whenNotActive" .../></smil ...>
If "foo" were defined with the default restartbehavior"always", a second activateEvent on the"bar" element would simply restart the element. However, since the secondactivateEvent cannot restart the element when
Note that in SMIL Language documents, a SMILelement cannot be visible before it begins so having atimeAction support, this may not be the case.For example, the following is reasonable:
<html ...>...<span begin="click" end="click" timeAction="class:highlight" restart="whenNotActive"> Click here to highlight. Click again to remove highlight.</span>...</html>
This is based upon the event sensitivitysemantics described in Eventsensitivity andUnifying Scheduling and InteractiveTiming.
This section is normative
The following attribute is provided to specify the default behavior for
Given the default values of this attribute ("inherit") and of therestart="always" behavior for all timed elements.
This section is normative
When a time container repeats or restarts, alldescendent children are "reset" with respect to certain state:
This section is informative
Thus, for example if an element specifies
This section is normative
When an element restarts, rules 1 and 2 are also appliedto the element itself, although rule 4 (controlling restart behavior) is notapplied.
Note that when any time container ends its simpleduration (including when it repeats), all timed children that are stillactive are ended.See alsoTime containerconstraints on child durations.
When anexcl timecontainer restarts or repeats, in addition to ending any active children, thepause queue for theexcl is cleared.
This section is informative
New support in SMIL 2.1 introduces finer grainedcontrol over the runtime synchronization behavior of a document. The
The
<par> <animation src="..." /> ... <par 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 todelivery problems, the entire "speech" par will pause, to keep the entiretimeline in sync. However, the rest of the document, including the animationelement will continue to play normally. Using the
This functionality also applies when an element firstbegins, and the media must begin to play. If the media is not yet ready (e.g.if an image file has not yet downloaded), the
An additional extension allows the author tospecify that a particular element should define or control thesynchronization for a time container. This is similar to the default behaviorof many user agents that "slave" video and other elements to audio, toaccommodate the audio hardware inaccuracies and the sensitivity of listenersto interruptions in the audio playback. The
In practice,linear media often need to be the syncMaster,where non-linear media can more easily beadjusted to maintain hard sync. However, a user agent cannot alwaysdetermine which media behaves in a linear fashion and which media behaves ina non-linear fashion. In addition, when there are multiple linear elementsactive at a given point in time, the user agent cannot always make the"right" decision to resolve sync conflicts. The
This section is normative
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
This section is informative
Note that the semantics of syncBehavior do not describe or require a particular approach to maintaining sync; the approach will be implementation dependent. Possible means of resolving a sync conflict may include:
Additional control is provided over the hard sync model using thesyncTolerance attribute. This specifies the amount of slip that can be ignored for an element. Small variance in media playback (e.g. due to hardware inaccuracies) can often be ignored, and allow the overall performance to appear smoother.
When any element is paused (including the cases described above for runtime sync behavior), the computed end time for the element may change or even become resolved, and the time model must reflect this. This is detailed in Paused elements and the active duration.
Two attributes are defined to specify the default behavior for runtime synchronization:
If an element slips synchronization relative to its parent, the amount of this slip at any point is described as theaccumulated synchronization offset. This offset is used to account for pause semantics as well as performance or delivery related slip. This value is used to adjust the conversion between element and parent times, as described inConverting between local and global times. The offset is computed as follows:
Lettc(tps) be the computed element active time for an element at the parent simple timetps, according to the defined synchronization relationship for the element.Letto(tps) be the observed element active time for an element at the parent simple timetps.
The accumulated synchronization offsetO is:
O = to(tps) - tc(tps)This offset is measured in parent simple time.
Thus an accumulated synchronization offset of 1 second corresponds to the element playing 1 second "later" than it was scheduled. An offset of -0.5 seconds corresponds to the element playing a half second "ahead" of where it should be.
The modularization of SMIL 2.1 functionality allows language designers to integrate SMIL Timing and Synchronization support into any XML language. In addition to just scheduling media elements as in SMIL language documents, timing can be applied to the elements of the host language. For example, the addition of timing to HTML (i.e. XHTML) elements will control the presentation of the HTML document over time, and to synchronize text and presentation with continuous media such as audio and video.
Two attributes are introduced to support these integration cases. ThetimeContainer attribute allows the author to specify that any XML language element has time container behavior. E.g., an HTML<ol> ordered list element can be defined to behave as a sequence time container. ThetimeAction attribute allows the author to specify what it means to apply timing to a given element.
XML language elements can be declared to have time container semantics by adding thetimeContainer attribute. The syntax is:
Constraints upon the use of thetimeContainer attribute are:
ThetimeAction attribute provides control over the effect of timing upon an attribute. A host language must specify which values are allowed for each element in the language. A host language must specify the intrinsic timing behavior of each element to whichtimeAction may be applied. In addition, a host language may specify additionaltimeAction values. The syntax is:
display" property should be controlled over time.visibility" property should be controlled over time.style" attribute.class attribute value list).Theintrinsic behavior is defined by a host language. For example in the SMIL language, theintrinsic behavior of media elements is to schedule and control the visibility of the media. For some elements or some languages, theintrinsic behavior may default to one of the other behaviors.
AdditionaltimeAction semantics and constraints:
visibility 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.style" attribute, thestyle value fortimeAction should not be allowed.class attribute), the class name should be removed from the class list of the element when the element is not active or frozen.Certain special elements may have specificintrinsic semantics. For example, linking elements likea andarea can have anintrinsic behavior that controls the sensitivity of the elements to actuation by the user. This may have presentation side-effects as well. In XHTML for example, making these elements insensitive also has the effect that the default styling (e.g. a color and underline) that is applied to sensitive links is removed when the element is not active or frozen.
Host language designers should carefully consider and define the behavior associated with applying timing to an element. For example,script elements could be defined to execute when the element begins, or the language could disallow thetimeAction attribute on the element. Similarly,linkelements could apply a linked stylesheet when the element begins or the language could disallow thetimeAction attribute onlink.
For details of the CSS propertiesvisibility anddisplay, see[CSS2].
The following example shows a simple case of controlling visibility over time. The text is hidden from 0 to 3 seconds, shown normally for 5 seconds, and then hidden again.
<span timeAction="visibility" begin="3s" dur="5s"> Show this text for a short period.</span>
The following example shows a simple case of controlling display over time. Each list element is shown for 5 seconds, and is removed from the layout when not active or frozen. The ordered list element is set to be a sequence time container as well (note that each list element retains its ordinal number even though the others are not displayed):
<ol timeContainer="seq" repeatDur="indefinite"> <li timeAction="display" dur="5s"> This is the first thing you will see. </li> <li timeAction="display" dur="5s"> You will see this second. </li> <li timeAction="display" dur="5s"> Last but not least, you will see this. </li></ol>
The following example shows how an element specific style can be applied over time. The respective style is applied to each HTMLlabel for 5 seconds after a focus event is raised on the element:
<form ...>... <label for="select_red"begin="focus" dur="5s" timeAction="style" > Make things RED. </label> <input .../> <label for="select_green"begin="focus" dur="5s" timeAction="style" > Make things GREEN. </label> <input .../>...</form>
This section is informative
SMIL 2.1 specifies three types of time containers. These can be declared with the elementspar,seq, andexcl, or in some integration profiles with atimeContainer attribute. Media elements with timed children are defined to be "media time containers", and have semantics based upon thepar semantics (see alsoAttributes for timing integration: timeContainer and timeAction andImplicit duration of media element time containers).
This document refers in general to time containers by reference to the elements, but the same semantics apply when declared with an attribute, and for media time containers.
This section is normative
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 is the same element introduced with SMIL 1.0.
Thepar element supports all element timing.
The implicit duration of apar is controlled byendsync. By default, the implicit duration of apar is defined by theendsync="last" semantics. The implicit duration ends with the last active end of the child elements.
This section is normative
This is the same element introduced with SMIL 1.0, but the semantics (and allowed syntax) for child elements of aseq are clarified.
Theseq element itself supports all element timing exceptendsync.
When a hyperlink traversal targets a child of aseq, and the target child is not currently active, part of the seek action must be to enforce the basic semantic of aseq that only one child may be active at a given time. For details, seeHyperlinks and timing and specificallyImplications of beginElement() and hyperlinking forseq andexcl time containers.
SMIL 2.1 defines a time container,excl, that allows the interactive (or a-temporal) activation of child elements.
This section is normative
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 the timegraph.
Theexcl element itself supports all element timing.
This section is informative
With theexcl time container, common use cases that were either difficult, or impossible, to author are now easier and possible to create. Theexcl time container is used to define a mutually exclusive set of clips, and to describe pausing and resuming behaviors among these clips. Examples include:
The interactive playlist use case above could be accomplished using apar whose sources have interactive begin times andend events for all other sources. This would require a prohibitively long list of values forend to maintain. Theexcl time container provides a convenient short hand for this - the element begin times are still interactive, but theend events do not need to be specified because theexcl, by definition, only allows one child element to play at a time.
The audio descriptions use case is not possible without the pause/resume behavior provided byexcl andpriorityClass. This use case would be authored with a video and each audio description as children of theexcl. The video element would be scheduled to begin when theexcl begins and the audio descriptions, peers of the video element, would start at scheduled begin times or in response to stream events raised at specific times.
The dynamic video sub-titles use case requires the "play only one at a time" behavior ofexcl. In addition, the child elements are declared in such a way so as to preserve the sync relationship to the video:
<smil ...>...<par endsync="vid1"> <video .../> <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 children of theexcl, and so only one can play at a time. The audio child in eachpar is defined to begin when the video begins. Each audio can only be active when the parent time container (par) is active, but the begin still specifies the synchronization relationship. This means that when eachpar begins, the audio will start playing at some point in the middle of the audio clip, and in sync with the video.
Theexcl time container is useful in many authoring scenarios by providing a declarative means of describing complex clip interactions.
This section is normative
This section is informative
Using priority classes to control the pausing behavior of children of theexcl allows the author to group content into categories of content, and then to describe rules for how each category will interrupt or be interrupted by other categories. Attributes of the new grouping elementpriorityClass describe the intended interactions.
EachpriorityClass element describes a group of children, and the behavior of those children when interrupted 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 theexcl begins (or would normally begin) while another is already active, several behaviors may result. The active element may be paused or stopped, or the interrupting element may be deferred, or simply blocked from beginning.
The careful choice of defaults makes common use cases very simple. See the examples below.
This section is normative
If nopriorityClass element is used, all the children of theexcl are considered to bepeers, with the defaultpeers behavior "stop".
This section is informative
Note that the rules define the behavior of the currently active element and the interrupting element. Any elements in the pause queue are not affected (except that their position in the queue may be altered by new queue insertions).
This section is normative
excl time container). The paused element is added to the pause queue.When an element begin is blocked (ignored) because of the"never" attribute value, the blocked element does not begin in the time model. The time model should not propagate begin or end activations to time dependents, nor should it raisebegin orend events.
This section is informative
ThepauseDisplay attribute controls the behavior when paused of the children of apriorityClass element. When a child of apriorityClass element is paused according toexcl andpriorityClass semantics, thepauseDisplay attribute controls whether the paused element will continue toshow orapply the element (i.e. the state of the element for the time at which it is paused), or whether it is removed altogether from the presentation (i.e.disabled) while paused.
This section is normative
="pause" orhigher="pause".This section is informative
Note that because of the defaults, the simple cases work without any additional syntax. In the basic case, all the elements default to be peers, and stop one another:
<excl dur="indefinite"> <audio .../> <audio .../> <audio .../> ... <audio .../></excl>
is equivalent to the following with explicit settings:
<excl dur="indefinite"> <priorityClass peers="stop"> <audio .../> <audio .../> <audio .../> ... <audio .../> </priorityClass></excl>
If the author wants elements to pause rather than stop, the syntax is:
<excl dur="indefinite"> <priorityClass peers="pause"> <audio .../> <audio .../> <audio .../> ... <audio .../> </priorityClass></excl>
The audio description use case for visually impaired users would look very similar to the previous example:
<excl dur="indefinite"> <priorityClass peers="pause"> <video .../> <audio begin="20s" dur="30s".../> <audio begin="2min" dur="30s" .../> ... <audio .../> </priorityClass></excl>
This example shows a more complex case of program material and several commercial insertions. The program videos will interrupt one another. The ads will pause the program, but will not interrupt one another.
<excl dur="indefinite"> <priorityClass peers="defer"> <video .../> <video .../> </priorityClass> <priorityClass peers="stop" higher="pause"> <video .../> <video .../> <video .../> <video .../> </priorityClass></excl>
The following example illustrates how defer semantics and priority groups can interact. When "alert1" tries to begin at 5 seconds, the "program"priorityClasswill force "alert1" to defer, and so "alert1" will be placed upon the queue. When "alert2" tries to begin 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 not active at 6 seconds, and so the interrupt semantics between "alert1" and "alert2" are not evaluated. The resulting behavior is that when "prog1" ends at 20 seconds, "alert1" will play, and then when "alert1" ends, "alert2" will play.
<excl dur="indefinite"> <priorityClass lower="defer"> <video begin="0" dur="20s" .../> </priorityClass> <priorityClass peers="never"> <video begin="5s" .../> <video begin="6s" .../> </priorityClass></excl>
This example illustratespauseDisplay control. When an element is interrupted by a peer, the interrupted element pauses and is shown in a disabled state. It is implementation dependent how the disabled video is rendered. Disabled elements do not respond to mouse events.
<excl dur="indefinite"> <priorityClass peers="pause" pauseDisplay="disable"> <video .../> <video .../> <video .../> ... <video .../> </priorityClass></excl>
In this example, when a child of a higherpriorityClass element interrupts a child of the "program"priorityClass, the child of "program" pauses and remains onscreen. If a peer of the "program"priorityClass interrupts a peer, the element that was playing stops and is no longer displayed.
<excl dur="indefinite"> <priorityClass peers="defer"> <video .../> <video .../> </priorityClass> <priorityClass peers="stop" higher="pause" pauseDisplay="show"> <video .../> <video .../> <video .../> <video .../> </priorityClass></excl>
This section is normative
Elements that are paused or deferred are placed in a priority-sorted queue of waiting elements.When an active element ends its active duration and the queue 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 for insertion and removal of elements. For the purposes of discussion, the child elements of apriorityClass element are considered to have the priority of thatpriorityClass, and to have the behavior described by thepeers,higher andlower attributes on thepriorityClass parent.
Note that if an element is active and restarts (subject to therestart rule), it does not interrupt itself in the sense of a peer interrupting it. Rather, it simply restarts and the queue is unaffected.
The runtime synchronization behavior of an element (described in thesyncBehavior,syncTolerance, andsyncMaster attributes: controlling runtime synchronization) does not affect the queue semantics. Any element that is paused or deferred according to the queue semantics will behave as described. When a paused element is resumed, the synchronization relationship will be reestablished according to the runtime synchronization semantics. The synchronization relationship for a deferred element will be established when the element actually begins.
When an element is paused, the calculated end time for the element may change or even become resolved, and the time model must reflect this. This is detailed in Paused elements and the active duration. In some cases, the end time is defined by other elements unaffected by the pause queue semantics. 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 end="joe.end" .../> <img begin="8s" dur="5s" .../> </priorityClass></excl>
If an element ends while it is in the pause queue, it is simply removed from the pause queue. All time dependents will be notified normally, and the end event will be raised at the end time, as usual.
When an element is deferred, the begin time is deferred as well. Just as described inPaused elements and the active duration, the begin time of a deferred element may become unresolved, or it may simply be delayed. In the following example, the "bar" element will initially have an unresolved begin time. If the user clicks on "foo" at 8 seconds, "bar" would resolve to 8 seconds, but will be deferred until 10 seconds (when "foo" ends):
<html ...>...<excl dur="indefinite"> <priorityClass peers="defer"> <img begin="0s" dur="10s" .../> <img begin="foo.click" .../> </priorityClass></excl>...</html>
If there is enough information to determine the new begin time (as in the example above), an implementation must compute the correct begin time when an element is deferred.The change to the begin time that results from the element being paused must be propagated to any sync arc time dependents (i.e. other elements with a begin or end defined relative to the begin of the deferred element).See also thePropagating changes to times section.
One exception to normal processing is made for deferred elements, to simplify the model: a deferred element ignores propagated changes to its begin time. This is detailed in theDeferred elements and propagating changes to begin section.
Although the default begin value for children of anexcl is indefinite, scheduled begin times are permitted. Scheduled begin times on children of theexcl cause the element to begin at the specified time, pausing or stopping other siblings depending on thepriorityClass settings (and default values).
If children of anexcl attempt to begin at the same time, the evaluation proceeds in document order. For each element in turn, the priorityClass semantics are considered, and elements may be paused, deferred or stopped.
This section is informative
The following examples both exhibit this behavior (it can result from any combination of scheduled times, interactive timing, hyperlink or DOM activation):
<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 src="image1.jpg" begin="foo.activateEvent" dur="5s"/> <img src="image2.jpg" begin="img1.begin" dur="5s"/> <img src="image3.jpg" begin="img2.begin" dur="5s"/></excl>...</smil>
In the first example, the images are scheduled to begin immediately, where in 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 the default interrupt semantics forexcl, the first image will begin and then be immediately stopped by the second image, which will in turn be immediately stopped by the third image. The net result is that only the third image is seen, and it lasts for 5 seconds. Note that the begin and end events for the first two images are raised and propagated to all time dependents. If the behavior is set to"pause" as in this example, the declared order is effectively 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 by the second image, which will in turn be immediately paused by the third image. The net result is that the third image is seen for 5 seconds, followed by 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 propagated to all time dependents when theexcl begins.
In the following slideshow example, images begin at the earlier of their scheduled begin time or when activated by a user input event:
<html ...>...<excl> <img src="image1.jpg" begin="0s".../> <img src="image2.jpg" begin="10s; image1.click".../> <img src="image3.jpg" begin="20s; image2.click".../></excl>...</html>
Note, some surprising results may occur when combining scheduled and interactive timing within anexcl. If in the above example, the user clicks on image1 and then on image2 before ten seconds have elapsed, image 2 will re-appear at the ten second mark. Image 3 will appear at twenty seconds. The likely intent of this particular use-case would be better represented with aseq time container.
This section is informative
Children of theexcl can be activated by scheduled timing, hyperlinks, events or DOM methods calls. For all but hyperlink activation, theexcl time container must be active for child elements of theexcl to be activated. With hyperlink activation, the document may be seeked to force the parentexcl to be active, and a seek may 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.
This section is normative
With activation via a DOM method call (e.g. thebeginElement() method), the element will be activated at the current time (subject to thepriorityClass semantics), even if the element has a scheduled begin time.The exclusive semantics of the time container (allowing only one active element at a time) and allpriorityClass semantics are respected nevertheless.
See alsoHyperlinks and timing and specificallyImplications of beginElement() and hyperlinking forseq andexcl time containers.
This section is normative
The implicit duration of a media time container combines the intrinsic duration of the media with the children to define the implicit simple duration. For the "ID-REF" value of endsync, the semantics are the same as for a normal time container. For the "media" value of endsync, implicit simple duration is equal to the intrinsic duration of the media directly associated with the element. For the values"first","last" and"all", the media element acts as apar time container, but treats the element's associated media as an additional condition as far as determining when the criteria for"first","last" and"all" endsync values have been satisfied.
If the implicit duration defined byendsync islonger than the intrinsic duration for a continuous media element, the ending state of the media (e.g. the last frame of video) will be shown for the remainder of the implicit duration. This only applies to visual media - aural media will simply stop playing.
This section is informative
This semantic is similar to the case in which the author specifies a simple duration that is longer than the intrinsic duration for a continuous media element. Note that for both cases, although the media element is effectively frozen for the remainder of the simple duration, the time container simple time is not frozen during this period, and any children will run normally without being affected by the media intrinsic duration.
Assume that "vid1" is 10 seconds long in the following examples.
The default value ofendsync for media elements is "media", and so the simple duration in the following example is 10 seconds. This will cut short theanimate child 8 seconds into its simple duration:
<video src="vid1.mpg" > <animate begin="2s" dur="12s" .../></video>
Specifyingendsync="first" in the example below causes the simple duration of the video element to be 10 seconds, since the media finishes before the animate child.
<video src="vid1.mpg" endsync="first" > <animate begin="2s" dur="12s" .../></video>
Specifyingendsync="last" in the following example causes the simple duration of the video element to be 14 seconds. The video will show a still frame (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 simple duration of the video element to last at least 10 seconds (the intrinsic duration of the video), and at most until 5 seconds after the user clicks on the video. The video will show a still frame (the last frame) for any duration in excess of 10 seconds:
<html ...>...<video src="vid1.mpg" endsync="all" > <set dur="8s" .../> <animate begin="click" dur="5s" .../></video>...</html>
Thus if the user clicks on the video after 1 second, the simple duration is 10 seconds. If the user does not click until 15 seconds, the simple duration is 20 seconds, and the last frame will be shown between 10 and 20 seconds. The video can still be clicked even though it stops normal play at 10 seconds.
In some language integrations, it will be possible to declare a media time container to have sequence or exclusive semantics, in addition to the default parallel semantics described above. For example:
<html ...>...<video src="vid1.mpg" timeContainer="seq" endsync="first" > <animate dur="4s" .../> <animate end="click" .../></video>...</html>
The animate children of thevideo will act in sequence. Theendsync semantics define a simple duration for thevideo that is no more than 10 seconds (the intrinsic duration of the video) but may be just over 4 seconds, if the user clicks on thevideo as soon as the lastanimate begins.
Except as noted, this entire section isnormative
A begin or end time is said to be unresolved when either an associated begin or end event has not yet occurred (within the constraints ofEvent sensitivity), or the begin or end time is dependent upon another element's begin or end time that is unresolved. The begin or end time becomes resolved as soon as the syncbase element's time is resolved, or when the event occurs (within the constraints ofEvent sensitivity).
If a begin or end value resolves to a time in the past, this value is propagated to other synchronization dependents. Similarly, a simple or active duration can be unresolved but can become resolved when end conditions are met or the parent time container constrains the element's duration.
A resolved time is said to bedefinite if it is not the value "indefinite".
Thesimple duration of an element is determined by thedur attribute, the implicit duration of the element, 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 available at the time the calculation is made. Unresolved quantities may require the simple duration to be recomputed when an unresolved quantity becomes resolved.
| 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
WhenrepeatCount is specified, it is understood to represent a count of iterations of simple duration. Each iteration of the simple duration may be different, and so a simple multiplication 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 not resolved, the most recent simple duration should be multiplied by the fractional part of therepeatCount to constrain the last simple duration. If the last iteration of the simple duration otherwise ends before this time, therepeatCount should be considered to be complete. If arepeatCount is less than 1 and the simple duration is unresolved, therepeatCount cannot be correctly respected, 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), nothing should be played even if therepeatDur specifies an active duration. The time model behaves according to the description, but no audio should be played.
If arepeatDur is shorter than the simple duration, or ifrepeatCount is less than 1, the active duration can cut short the defined simple duration.
IfrepeatDur is "indefinite" and neither ofrepeatCount orend are specified, the active duration is indefinite. IfrepeatCount is indefinite, the simple duration is greater than 0 and neither ofrepeatDur orend are specified, then the active duration is indefinite.
Note that unlike in SMIL 1, when an element defines a begin offset and repeat behavior withrepeatCount orrepeatDur, the begin offset isnot included in each repeat.
Theactive duration of an element defines the entire period that an element's timeline is active. It takes into account the elementsimple duration evaluated above, theend attribute, and any repeat behavior defined by therepeatDur andrepeatCount attributes.
Computing the active duration requires defining arithmetic operations on all of the possible values that simple duration can have.
Whereanything means zero value, non-zero value, indefinite, or unresolved.
This section is informative
In this section, references tobegin andend values should be understood as the current effective values in each respective value list. These values are determined by the rules described inEvaluation of begin and end time lists.
This section is normative
The following symbols are used in the algorithm as a shorthand:
Computation of the active duration is based on the information available at the time the calculation is made. Unresolved quantities may require the active duration to be recomputed when an unresolved quantity becomes resolved.
To compute the active duration, use the following algorithm:
Ifendis specified, and none ofdur,repeatDur, andrepeatCount are specified, then the simple duration isindefinitefrom the simple duration table above, and the active duration is defined by theend value, according to the following cases:
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, then the active duration is determined from theIntermediate Active Duration computation given below:
PAD =Result from Intermediate Active Duration Computation
Otherwise, anendvalue not equal toindefinite is specified along with at least one ofdur,repeatDur, andrepeatCount. Then thePAD is the minimum of the result from theIntermediate Active Duration Computation 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 active durationPAD. In the following expression, if there is nomin value, substitute a value of 0, and if there is nomax value, substitute a value of "indefinite":
AD = MIN(max, MAX(min,PAD ))
We define three intermediate quantities, p0, p1, and p2, and produce an intermediate result, theIntermediate Active Duration (IAD) to be used in the computation above.
p0 is the simple duration from the Simple Duration Table, given above.
IfrepeatCountis not specified,p1 has the valueindefinite. Otherwise,p1 is the accumulated sum of the specified number of simple durations of the iterations of this element.p1 will have a value of unresolved until the simple duration for each iteration is resolved. Partial iterations will contribute the specified fraction of the simple duration to the sum. This product can be based on either the known fixed simple duration of the media, or if unknown, the simple duration from the previous iteration of the current set of repetitions. In general for media without a fixed simple duration,p1 will not be resolved until the specified integral number 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 unspecified then:
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 the specified simple duration. If the user activates "foo" before 5 seconds, theend value becomes resolved and the active duration is re-evaluated. This causes the element to end at the time of the activation.
Some of the rules and results that are implicit in the algorithm, and that should be noted in particular are:
It is possible to combine scheduled and interactive timing. For example:
<smil ...>...<par dur="30s"> <img 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 the audio is initially defined to be indefinite because its end time is unresolved. 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 time container will constrain playback.
It is possible to declare both a scheduled duration, as well as an event-based active end. This facilitates what are sometimes called "lazy interaction" use-cases, such as a slideshow that will advance in response to user clicks, or on its own after a specified amount of time:
<html ...>...<seq> <img src="slide1.jpg" dur="10s" end="click" /> <img src="slide2.jpg" dur="10s" end="click" /> <img src="slide3.jpg" dur="10s" end="click" /> <!-- etc., etc. --></seq>...</html>
In this case, the active end of each element is defined to be the earlier of the specified duration, or a click on the element. This lets the viewer sit back and watch, or advance the slides at a faster pace.
An element can be paused while it is active. This may happen in a number of ways, including via a DOM method call or because of excl semantics.When an element is paused, a resolved end time for the element may change, or it may become unresolved. The synchronization relationship between the paused element and its parent time container is re-established when the paused element is resumed. If for example the element below is paused with a DOM method call, there is no way to know when the element will end, and so the end time must be considered unresolved:
<img dur="30s" .../>However, in the following case, the "bar" element will still end at 10 seconds, even if it is paused at 8 seconds. In this case, the end time does not change:
<img dur="10s" .../><img end="foo.end" .../>
Finally, in the following case the "foo" element will initially be computed to end at 10 seconds. If the "bar" element begins (i.e. if the user activates 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 dur="10s" .../> <img begin="foo.activateEvent" dur="5s" .../> </priorityClass></excl>...</smil>
If there is enough information to determine the new end time (as in the example above), an implementation must compute the correct end time when an element is paused.Any change to the end time that results from the element being paused must be propagated to any sync arc time dependents (i.e. other elements with a begin or end defined relative to the active end of the paused element).See also thePropagating changes to times section.
In addition, when an element is paused, the accumulated synchronization offset 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 time container ends. In this case, any fill behavior is interpreted using the element active time when the element ends (that is, it will use the element active time at which it was paused to determine what to display).
This section isinformative
Children of par and excl time containers can have multiple begin and end values. We need to specify the semantics associated with multiple begin and end times, and how a dynamic timegraph model works with these multiple times.
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 is played, more than one interval may be created for an element with multiple begin and end times. At any given moment, there is onecurrent interval associated with each element. Intervals are created by evaluating a list of begin times and a list of end times, each of which is based upon theconditions described in the begin and end attributes for the element.
The list of begin times and the list of end times used to calculate new intervals are referred to as lists of "instance times". Each instance time in one of the lists is associated with the specification of a begin or end condition defined in the attribute syntax. Some conditions - for example offset-values - only have a single instance in the list. Other conditions may have multiple instances if the condition can happen more than once. For example a syncbase-value can have multiple instance times if the syncbase element has played several intervals, and an event-value may have multiple instance times if the event has happened more than once.
The instance times lists for each element are initialized when the timegraph is initialized, and exist for the entire life of the timegraph. Some instance times such as those defined by offset-values remain in the lists forever, while others may come and go. For example, times associated with event-values are only added when the associated event happens, and are removed when the elementresets, as described inResetting element state. Similarly, Instance times for syncbase-values are added to the list each time a new interval is created for the syncbase element, but these instance times are not removed by a reset, and remain in the list.
When the timegraph is initialized, each element attempts to create a first current interval. The begin time will generally be resolved, but the end time may often be unresolved. If the element can restart while active, the current interval can end (early) at the next begin time. This interval will play, and then when it ends, the element will review the lists of begin and end instance times. If the element should play again, another interval will be created and this new interval becomes thecurrent interval. The history 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 of the instance times for theend changes while the current interval is playing, the current interval end will be recomputed and may change. Nevertheless, once a time hashappened, it is fixed. That is, once the current interval has begun, its begin time can no longer change, and once the current interval has ended, its end time can no longer change. For an element to restart, it must end the current interval and then create a new current 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 as a relationship between the two elements. This level of dependency is important to the model when an element creates a new current interval. However, for the purposes of propagating changes to individual times, time dependencies are more specifically a dependency from a giveninterval of the syncbase element to a particularinstance time in one of the dependent element's instance time lists. Since only the current interval's begin and end times can change, only the current interval will generate time-change notices and propagate these to the dependent instance times.
When this section refers to the begin and end times for an element, the times are described as being in the space of the parent simple duration. All sync-arcs, event arcs, wallclock values, etc. must be converted to this time space for easy comparison. This is especially important when referring to begin times "before 0", which assumes that "0" is the beginning of the parent simple duration. The model does not depend upon this definition - e.g. an implementation could do everything in global document time.
Cycles in the timegraph must be detected and broken to ensure reasonable functioning of the implementation. A model for how to do this in the general case is described (it is actually an issue that applies even to SMIL 1.0). A mechanism to support certain useful cyclic dependencies falls out of the model.
The rest of this section details the semantics of the instance times lists, the element life cycle, and the mechanisms for handling dependency relationships and cycles.
This section is normative
Instance lists are associated with each element, and exist for the duration of the document (i.e. there is no life cycle for instance lists). Instance lists may change, and some times may be added and removed, but the begin and end instance times lists are persistent.
Each element can have a begin attribute that defines one or more conditions that can begin the element. In addition, the timing model describes a set of rules for determining the end of the element, including the effects of an end attribute that can have multiple conditions. In order to calculate the times that should be used for a given interval of the element, we must convert the begin times and the end times into parent simple time, sort each list of times (independently), and then find an appropriate pair of times to define an interval.
The instance times can be resolved or unresolved. In the case of the end list, an additional special value "indefinite" is allowed. The lists are maintained in sorted order, with "indefinite" sorting after all other resolved times, and unresolved times sorting to the end.
For begin, the list interpretation is straightforward, since begin times are based only upon the conditions in the attribute or upon the default begin value if there is no attribute. However, when a begin condition is a syncbase-value, the syncbase element may have multiple intervals, and we must account for this in the list of begin times associated with the conditions.
For end, the case is somewhat more complex, since the end conditions are only one part of the calculation of the end of the active duration. The instance times list for end are used together with the other SMIL Timing semantics to calculate the actual end time for an interval.
If an instance time was defined as syncbase-values, the instance time will maintain a time dependency relationship to the associated interval for the syncbase element. This means that if the associated begin or end time of the syncbase current interval changes, then the dependent instance time for this element will change as well.
When an element creates a new interval, it notifies time dependents and provides the begin and end times that were calculated according to the semantics described in "Computing the active duration". Each dependent element will create a new instance time tied to (i.e. with a dependency relationship to) the new syncbase current interval.
The translation of begin or end conditions to instance times depends upon the type of condition:
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 yields one 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 call creates 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 interval will evaluate restart semantics and may ignore the new time or it may end the current interval (this is detailed inInteraction with restart semantics). In contrast, when an instance time in the begin list changes because the syncbase (current interval) time moves, this does not invoke restart semantics, but may change the current begin time: If the current interval has not yet begun, a change to an instance time in the begin list will cause a re-evaluation of the begin instance lists, which may cause the interval begin time to change. If the interval begin time changes, atime-change notice must be propagated to all dependents, and the current interval end must also be re-evaluated.
When a new instance time is added to the end list, or when an instance time in the end list changes, the current interval will re-evaluate its end time. If it changes, it must notify dependents.
If an element has already played all intervals, there may be no current interval. In this case, additions to either list of instance times, as well as changes to any instance time in either list cause the element to re-evaluate the lists just as it would at the end of each interval (as described inEnd of an interval below). This may or may not lead to the creation of a new interval for the element.
When times are added to the instance times lists, they may or may not be resolved. If they are resolved, they will be converted to parent simple time. If an instance time changes from unresolved to resolved, it will be similarly converted.
There is a difference between an unresolved instance time, and a begin or end condition that has no associated instance. If, for example, an event value condition is specified in the end attribute, but no such event has happened, there will be no associated instance time in the end list. However, if a syncbase value condition is specified for end, and if the syncbase element has a current interval, there will be an associated instance time in the end list. Since the syncbase value condition can be relative to the end of the syncbase element, and since the end of the syncbase current interval may not be resolved, the associated instance time in the end list can be unresolved. Once the syncbase current interval actually ends, the dependent instance time in the end list will get a time-change notification for the resolved syncbase interval end. The dependent instance time will convert the newly resolved syncbase time to a resolved time in parent simple time. If the instance lists did not include the unresolved instance times, some additional mechanism would have to be defined to add the end instance time when the syncbase element's current interval actually ended, and resolved its end time.
The list of resolved times includes historical times defined relative to sync base elements, and so can grow over time if the sync base has many intervals. Implementations may filter the list of times as an optimization, so long as it does not affect the semantics defined herein.
This section isinformative
The following set of principles underlie the interval model. This is not a complete model - it is just meant provide an additional view of the model.
First we define the termspruning andcutting off an interval - 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 information becomes 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 be removed 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 time containers, a valid interval for a child may not be shown, even though it is otherwise legal with respect to the parent time constraints. For example:
<par begin="-10s" dur="20s"> <img src="slide1.jpg" dur="3s" /> <img src="slide2.jpg" begin="slide1.end+3s" dur="10s" /> <img 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 before its parent time container, and instead will be started at 0s into its parent time synced at 10s into its simple duration. The "slide1" image begins and ends before 10s into the par, and so cannot be shown and iscut off, Intervals that arecut offare not shown and do not raise begin or end events, but still create valid instance times for any syncbase time dependents. Thus, "slide2" will be shown (the interval is from minus 4 seconds to 6 seconds, document time, and so will be shown for 6 seconds, from 0 seconds to 6 seconds), but "note1" will not be shown.
The principles underlying the interval life cycle model are:
An implication of principle 5 is that we will get no intervals withunresolved begin times, since these will necessarily compare >= the parent simple end.
This section is normative
The life cycle of an element can be thought of as the following basic steps:
Steps 2 to 5 can loop for as many intervals as are defined before the end of the parent simple duration. At any time during step 2, the begin time for the current interval can change, and at any time during steps 2 or 3, the end time for the current interval can change. When either happens, the changes are propagated to time dependents.
When the document and the associated timegraph are initialized, the instance lists are empty. The simple offset values and any "indefinite" value in an end attribute can be added to the respective lists as part of initialization, as they are independent of the begin time of parent simple time.
When an element has played all allowed instances, it can be thought of as stuck in step 5. However any changes to the instance lists during this period cause the element to jump back to step 4 and consider the creation of a new current interval.
An element life cycle begins with the beginning of the simple duration for the element's parent time container. That is, each time the parent time container (or more generallyanyascendant time container) repeats or restarts, the element resets (see alsoResetting element state) and starts "life" anew.
Three things are important about the beginning of the life-cycle:
Action 1) is also described inResetting element state. This action also happens each time the element restarts, although in that case the element must not clear an event time that defined the current begin of the interval.
Action 2) Simply updates values to reflect the current sync relationship of the parent simple duration to the rest of the document.
The third action requires some special consideration of the lists of times, but is still relatively straightforward. It is similar to, but not the same as the action that applies when the element ends (this is described inEnd of an interval). The basic idea is to find the first interval for the element, and make that the current interval. However, the model should handle three edge cases:
Thus the strict definition of the first acceptable interval for the element is the first interval that ends after the parent simple begin, and begins before the parent simple end. Here is some pseudo-code to get the first interval for an element. It assumes an abstract type "Time" that supports a compare function. It can be a resolved numeric value, the special value INDEFINITE (only used with end), and it can be the special value UNRESOLVED. Indefinite compares "greater than" all resolved values, and UNRESOLVED is "greater than" both resolved values and INDEFINITE. The code uses 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 getFirstIntervalNote that while we might consider the case ofrestart=always separately fromrestart=whenNotActive, it would just be busy work since we need to find an interval that beginsaftertempEnd.
If the model yields no first interval for the element, it will never begin, and so there is nothing more to do at this point. However if there is a valid interval, the element must notify all time dependents that there is anew interval of the element. This is a notice from this element to all elements that are direct time dependents. This is distinct from the propagation of a changed time.
When a dependent element gets a "new interval" notice, this includes a reference to the new interval. The new interval will generally have a resolved begin time and may have a resolved end time. An associated instance time will be added to the begin or end instance time list for the dependent element, and this new instance time will maintain a time dependency relationship to the syncbase interval.
This period only occurs if the current interval does not begin immediately when (or before) it is created. While an interval is waiting to begin, any changes to syncbase element current interval times will be propagated to the instance lists and may result in a change to the current interval.
If the element receives a "new interval" notice while it is waiting to begin, it willaddthe associated time (i.e. the begin or end time of the syncbase interval) to the appropriate list of resolved times.
When an instance time changes, or when a new instance time is added to one of the lists, the element will re-evaluate the begin or end time of the current interval (using the same algorithm described in the previous section). If this re-evaluation yields a changed interval, time change notice(s) will be sent to the associated dependents.
It is possible during this stage that the begin and end times could change such that the interval would never begin (e.g. the interval end is before the interval begin). In this case, the interval must bepruned and all dependent instance times must be removed from the respective instance lists of dependent elements. These changes to the instance lists will cause re-evaluation of the dependent element current intervals, in the same manner as a changed instance time does.
One exception to normal processing is made for elements that aredeferred according toexcl interrupt semantics: a deferred element ignores propagated changes to its begin time. This is detailed in theDeferred elements and propagating changes to begin section.
This period occurs when the current interval is active (i.e. once it has begun, and until it has ended). During this period, the end time of the interval can change, but the begin time cannot. If any of the instance times in the begin list change after the current interval has begun, the change will not affect the current interval. This is different from the case ofaddinga new instance time to the begin list, whichcancause a restart.
If the element receives a "new interval" notice while it is active, it willaddthe associated time (i.e. the begin or end time of the syncbase interval) to the appropriate list of resolved times. If the new interval adds a time to the begin list, restart semantics are considered, and this may end the current interval.
If restart is set to "always", then the current interval will end early if there is an instance time in the begin list that is before (i.e. earlier than) the defined end for the current interval. Ending in this manner will also send a changed time notice to all time dependents for the current interval end. See alsoInteraction with restart semantics.
If an element specifiesrestart="never" then no further action is taken at the end of the interval, and the element sits in the "post interval" state unless and until an ascendant time container repeats or restarts.
If an element specifies other values forrestart, when it ends the current interval the element must reconsider the lists of resolved begin and end times. If there is another legal interval defined to begin at or after the just completed end time, a new interval will be created. When a new interval is created it becomes thecurrent interval and a new interval notice is sent to all time dependents.
The algorithm used is very similar to that used in step 1, except that we are interested in finding an interval that begins after the most recent end.
// 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 getNextIntervalThis period can extend from the end of an interval until the beginning of the next interval, or until the end of the parent simple duration (whichever comes first). During this period, any fill behavior is applied to the element. The times for this interval can no longer change. Implementations may as an optimization choose to break the time dependency relationships since they can no longer produce changes.
There are two cases in which restart semantics must be considered:
restart="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.restart="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.restart="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).restart="always" then case 1 above applies, and will cause the current interval to end.There are two types of cycles that can be created with SMIL 2.1,closed cycles andopen orpropagating cycles. Aclosed cycle results when a set of elements has mutually dependent time 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 elements has mutually dependent time conditions, but at least one of the conditions involved has more than one resolved condition. If any one of the elements in the cycle can generate more than one interval, the cycle can propagate. In some cases such as that illustrated in example 3, this can be very useful.
Times defined in a closed cycle are unresolved, unless some external mechanism resolves one of the element time values (for example a DOM method call or the traversal of a hyperlink that targets one of the elements). If this happens, the resolved time will propagate through the cycle, resolving all the associated time values.
Closed cycles are an error, and may cause the entire document to fail. In some implementations, the elements in the cycle may just not begin or end correctly. Examples 1 and 2 describe the most forgiving behavior, but implementations may simply reject a document with a closed cycle.
Implementations can detect cycles in the timegraph using avisited flag on each element as part of the processing that propagates changes to time dependents. As a changed time notice is propagated, each dependent element is marked as having beenvisited. If the change to a dependent instance time results in a change to the current interval for that element, this change will propagate in turn to its dependents. This secondchainednotice happens in the context of the first time-change notice that caused it. The effect is like a stack that builds as changes propagate throughout the graph, and then unwinds when all changes have propagated. If there is a dependency cycle, The propagation path will traverse an element twice during a given propagation chain. This is a common technique used in graph traversals.
A similar approach can be used when building dependency chains during initialization 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 element that detected the second visit ignores the second change notice, and so breaks the cycle.
Example 1: In the following example, the 2 images define begin times that are mutually dependent. There is no way to resolve these, and so the images will never begin.
<img begin="bar.begin" .../><img begin="foo.begin" .../>
Example 2: In the following example, the 3 images define a less obvious cycle of begin and end times that are mutually dependent. There is no way to resolve these. The image "joe" will begin but will never end, and the images "foo" and "bar" will never begin.
<img begin="joe.end" .../><img begin="foo.begin" dur="3s" .../><img begin="0" end="bar.end" .../>
Example 3: In the following example, the 2 images define begin times that are mutually dependent, but the first has multiple begin conditions that allow the cycle to propagate forwards. The image "foo" will first be displayed from 0 to 3 seconds, with the second image "bar" displayed from 2 to 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 so the cycle keeps going forward. As this overlapping "ping-pong" behavior is not otherwise easy to author, these types of cycles are not precluded. Moreover, the correct behavior will fall out of the model described above.
<img begin="0; bar.begin+2s" dur="3s" .../><img begin="foo.begin+2s" dur="3s" .../>
Example 4: In the following example, an open cycle is described that propagates backwards. The intended behavior does not fall out of the model, and is not supported. In this example, however, each time the parent time container repeats, the video elements will begin two seconds earlier than they did in the previous parent iteration. This is because the begin instance times associated with syncbase value conditions are not cleared when the parent repeats. By the last iteration of the parent time container, both video elements would begin so early that they will be completely cut off by the parent begin constraint.
<par dur="10s" repeatCount="11" > <video begin="0; bar.begin-1s" dur="10s" .../> <video begin="foo.begin-1s" dur="10s" .../></par>
This section is informative
In this specification, elements are described as having local "time". In particular, many offsets are computed in thesimple time of a parent time container. However, simple durations can be repeated, and elements can begin and restart in many ways.
This section is normative
This section is informative
The SMIL timing model assumes the most common model forinterval timing.
This section is normative
This section is informative
This is also referred to asend-point exclusive timing. This model makes arithmetic for intervals work correctly, and provides sensible models for sequences of intervals.
In the real world, this is equivalent to the way that seconds add up to minutes, and minutes add up to hours. Although a minute is described as 60 seconds, a digital clock never shows more than 59 seconds. Adding one more second to "00:59" does not yield "00:60" but rather "01:00", or 1 minute and 0 seconds. The theoretical end time of 60 seconds that describes a minute interval 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 it begins at 15 (and not at 15 plus some minimum interval). When a runtime actually 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 rather should only show the new element "B". This is the same for audio, or for any interval on a timeline. If the model does not use endpoint-exclusive timing, it will draw overlapping frames, or have overlapping samples of audio, of sequenced animations, etc.
Note that transitions from "A" to "B" also adhere to the interval timing model. Theydo require that "A" not actually end at 15, and that both elements actually overlap. Nevertheless, the "A" duration is simply extended 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 no longer needed.
For the time model, several results of this are important: the definition of repeat, and the state of the element applied or displayed when the element is "frozen".
When repeating an element's simple duration, the arithmetic follows the end-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 video is presented. This is theinclusive begin of the interval. The simple duration proceeds normally up to 4 seconds.
This section is normative
simpleTime = REMAINDER( t,d ) where t is within the active duration
Note: REMAINDER( t, d ) is defined ast - (d*floor(t/d))
Using this, a time of4 (or 8 or 12) maps to the time of0 on the simple duration. The endpoint of the simple duration isexcluded from (i.e. not actually sampled on) the simple duration.
For most continuous media, this aligns to the internal media model, and so no frames (or audio samples) are ever excluded. However for sampled timeline media (like animation), the distinction is important, and requires a specific semantic for elements that are frozen.
The effect of this semantic upon animation functions is detailed in the[SMIL-ANIMATION] module.
This section is informative
The SMIL 2.1 timing model supports synchronization based upon unpredictable events such as DOM events or user interface generated events. The model for handling events is that the notification of the event is delivered to the timing element, and the timing element uses a set of rules to resolve any synchronization dependent upon the event.
Note:
This section is normative
The semantics of element sensitivity to events are described by the following set of rules:
It is important to notice that in no case is a single event occurrence used 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 begin="link9.activateEvent"> <img begin="link9.activateEvent" .../></par>...</smil>
Various alternative approaches can be used. One possible approach is to define the descendent element to begin relative to the ascendant begin, as in the following example (the begin rule for the image could be simpler, but this illustrates the general point):
<smil ...>...<par begin="link9.activateEvent"> <img begin="better_example.begin" .../></par>...</smil>
The event sensitivity rules can be used with the restart attribute to describe "toggle" activation use cases, as described in the section:Using restart for toggle activation.
Since the same event instance cannot be used to resolve both the begin and end time on a single element, uses like the following will have behavior that may seem non-intuitive to some people:
<html ...>...<audio src="bounce.wav" begin="foo.click" end="foo.click+3s" restart="whenNotActive"/>...</html>
This example will begin repeating the audio clip when "foo" is clicked, and stop the audio clip 3 seconds after "foo" is clickeda second time. It is incorrect to interpret this example as playing the audio clip for 3 seconds after "foo" is clicked. For that behavior, the following markup should be used:
<html ...>...<audio src="bounce.wav" begin="foo.click" dur="3s" restart="whenNotActive"/>...</html>
The timing model and the user event model are largely orthogonal. While the timing model does reference user events, it does not define how these events are generated, and in particular does not define semantics of keyboard focus, mouse containment, "clickability", and related issues. Because timing can affect the presentation of elements, it may impact the rules for user event processing, however it only has an effect to the extent that the presentation of the element is affected.
In particular, many user event models will make no distinction between an element that is "playing" and one that is "frozen". The effects of thefill attribute apply only to the timing semantics. If an element is still visible while frozen, it behaves normally with 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.
Related to event-activation islink-activation. Hyperlinking has defined semantics in SMIL 1.0 to seek a document to a point in time. When combined with interactive timing (e.g.begin="indefinite"), hyperlinking yields a variant on user-interactive content.
This section is normative
The details of when hyperlinks activate an element, and when they seek the document timeline are presented in the sectionHyperlinks and timing.
This section is normative
To convert a document time to an element local time, the original time is converted to a simple time for each time container from the root time container down to the parent time container for the element. This recursive algorithm allows for a simple model of the conversion from parent simple time to element active and element simple time. The first step calculates element active time, and the second step calculates element simple time.
The steps below assume that the associated times are resolved and not indefinite. If a required time is not resolved or is indefinite, then the conversion is not defined, and cannot be performed.
The input time is a time in parent simple time. This is normalized to the element active duration, adjusting for the accumulated synchronization offset (described inThe accumulated synchronization offset).
Lettps 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 timeta for any child element is:
ta =tps - B - O
The element simple time is the time that is used to establish runtime synchronization for a media element, or to compute an animation function's input value or sampling time. If the element is a time container, this is also the time that is seen by all children of a time container (as the time container element's simple time).
To compute the element simple timets from an element active timeta, accounting for any repeat behavior:
If there is no repeating behavior:ts = taElse, the element simple time is just computed from the begin time of the most recent iteration - call thistlast-repeat. Some other mechanism (such as endsync logic or a media player) must note when the simple duration ends, and reset the value oftlast-repeat. If the element has not yet repeated, a value of 0 is used in place oftlast-repeat.
ts = ta - tlast-repeat
Note that the above semantic covers the special (ideal) case when the simple durationdur is fixed and does not vary. In this case (and this case only)tlast-repeat can be obtained directly for the simple durationdur and so the expression can be reduced to:
ts = REMAINDER( ta, dur )whereREMAINDER( t, d ) is defined as(t - d*floor(t/d)).
When the document begins, the current wall-clock time is noted and saved astwallclock-begin. To convert a wall-clock valuetwc to an element active simple timets, first converttwc to a document global timetra (i.e. an element active time for the root time container):
tra = twc - twallclock-begin
This may yield a negative time if the wallclock value is a time before the document began. Nevertheless, this is a legal value.
The timetrais then converted normally to element active time or element local time as needed.
Event times are generally stamped with a time relative to system time or when the document began. The conversion is as for wallclock values, in that the event time is converted to an active time for the root time container, and then converted normally to an element time.
To convert from one element timespace to another, the time for the first elementte1 must first be converted to a simple time on the closest ascendant time container that contains both elements. Converting from an element time to the parent time reverses the process described above. Again, it is recursive, and so the conversions are described generically from element simple to element active time, and from element active to parent simple time.
To convert from element simple time to element active time requires the begin time of the most recent iteration,tlast-repeat. If the element does not repeat or has not yet repeated, a value of 0 is used in place oftlast-repeat.
ta = ts + tlast-repeat
Conversion from element active time to parent simple time uses the associated begin of the element and the accumulated synchronization offset.
tps =ta + B + O
Note that the pure conversions do not take into account the clamping of active durations, nor the effects of fill (where time is frozen).Global to local time conversions used to translate between timespaces must ignore these issues, and so may yield a time in the destination local timespace that is well before or well after the simple duration of the element.
An alternate form of the conversion is used when actually sampling the time graph.A time container is only sampled if it is active or frozen, and so no times will be produced that are before a time container begins. If the global to local time conversion for a time container yields a time during which the time container is frozen, the time is clamped to the value of the active end.
This section is informative
Hyperlinking semantics must be specifically defined within the time model in order to ensure predictable behavior. Earlier hyperlinking semantics, such as those defined by SMIL 1.0 are insufficient because they do not handle unresolved times, nor do they handle author-time restart restrictions. Here we extend SMIL 1.0 semantics for use in presentations using elements with unresolved timing (including interactive timing) and author-time restart restrictions.
This section isnormative
A hyperlink may be targeted at an element by specifying the value of theid attribute of an element in the fragment part of the link locator. Traversing a hyperlink that refers to a timed element will behave according to the following rules:
In the above rules, the following additional constraint must also be respected:
This section is informative
Note that the first constraint means that a hyperlink to a child of a time container will never seek to a time earlier than the beginning of the time container. The second constraint implies that a hyperlink to a child that begins after the end of the parent simple duration will seek to the end of the parent, and proceed from there. While this may produce surprising results, it is the most reasonable fallback semantic for what is essentially an error in the presentation.
If a seek of the presentation time is required, it may be necessary to seek either forward or backward, depending upon the resolved begin time of the element and the presentation current time at the moment of hyperlink traversal.
This section isnormative
beginEvent,endEvent and anyrepeatEvent events are not raised.endEvent is raised. The associated time for the event is the document time before the seek.repeatEvents are not raised.The net effect is that seeking forward to a presentation time puts the document into a state largely identical to that as if the document presentation time advanced undisturbed to reach the seek time. If the presentation is authored with nobeginEvent,endEvent orrepeatEvent based timing and no automatic hyperlinks, then state of the document after a seek should be identical to that had the document presentation time advanced undisturbed to reach the seeked-to time.
If the resolved activation time for an element that is the target of a hyperlink traversal occurs in the past, the presentation time must seek backwards. Seeking backwards will rewind any elements active at the time of hyperlinking.
beginEvent,endEvent orrepeatEvent events.endEvent 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.repeatEvents are not raised.This section is informative
These hyperlinking semantics assume that a record is kept of the resolved begin time for all elements, and this record is available to be used for determining the correct presentation time to seek to. For example:
<html ...>...<par begin="0"><img begin="10s" .../><img begin="A.begin+5s" .../><img begin="B.click" .../><img begin="C.begin+5s" .../>...<a href="#D">Begin image D</a></par>...</html>
The begin time of elementsA andB can be immediately resolved to be at 10 and 15 seconds respectively. The begin of elementsC andD are unresolved when the document 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 the presentation. The click onB resolves the begin ofC; this in turn resolvesD to begin at 30 seconds. From this point on, traversing the hyperlink will cause the presentation 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 a presentation time of 65 seconds. Subsequent activation of the hyperlink whileD is active will result in the seeking the presentation to 65 seconds. If the hyperlink is activated whenD is no longer active, the presentation will seek to the earliest resolved begin time ofD, at 30 seconds.
This section is normative
For a child of a sequence time container, if a hyperlink targeted to the child is traversed, this seeks the sequence to the beginning of the child.
endEventevent is raised, with the current time as the associated event time.beginElement() 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).This section is informative
Note that if a hyperlink targets (or ifbeginElement() orbeginElementAt() is called for) an elementA defined to begin when another elementB ends, and the other elementB has (e.g.) an event-base or syncbase end, the hyperlink or method call will not end elementB. It will only activate elementA. If the two elements are siblings within aseq orexcl time container, the parent time container enforces its semantics and stops (or pauses) the running element.
If a hyperlink targets a child of anexcl time container, activating the linkwill seek to the earliest computed begin. This means that pause/defer stack semantics do not need to be accounted for when linking to an element. Instead the document timeline will simply be seeked to the first resolved time for the element, or seeked to the start of the time container and the target element simply started if there is no resolved begin time.
This section is informative
There are several cases in which times may change as the document is presented. In particular, when an element time is defined relative to an event, the time (i.e. the element begin or active end) is resolved when the event occurs. Another case arises with restart behavior - the element gets a new begin and active end time when it restarts. Since the begin and active end times of one element can be defined relative to the begin or active end of other elements, any changes to times must be propagated throughout the document.
When an element "foo" has a begin or active end time that specifies a syncbase element (e.g. "bar" as below):
<img 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 the active 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 propagated change depends upon the state of "foo" when the change happens.
This section is normative
One exception to normal processing is made for elements that aredeferred according toexcl interrupt semantics. This exception is made to simplify the model: once an element is deferred, it will stop normal handling of time change notices that are propagated to the element begin conditions, as time dependents of syncbase elements. That is, with respect to the behavior of the element as a time dependent, the element behaves as though it had already begun. This exception is made so that the deferred element cannot change its begin time due to syncbase element changes, while it is deferred. In effect, the elementshould have begun at the time it was deferred, and so it should no longer handle changed time notices.
This section is informative
In some cases, the semantics of restart may preclude the correct propagation of changes to time, as in the following example:
<html ...>...<par> <img dur="10s" end="click" .../> <video begin="img1.end-3s" restart="whenNotActive" .../></par>...</html>
If the user clicks the image at 8 seconds, the image will end at that point, and the changed end time will propagate to the video. However, the video will have begun at 7 seconds (3 seconds before the calculated end of 10 seconds), and cannot restart. The propagated change will be ignored. See alsoInteraction with restart semantics in the section onEvaluation of begin and end time lists.
This section is informative
The implicit duration of a time container is defined in terms of the children of the container. The children can be thought of as the "media" that is "played" by the time container element. The semantics are specific to each of the defined time container variants, and are described in the respective sections: Thepar element, theseq element, and theexcl element.
Note that the term "computed values" should not be confused with the values of times that are dynamic within the time graph. In the following example, 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. If the 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 an implementation as 10 seconds, the endsync semantics must be evaluated with the updated times that account for the user events.
<smil ...>...<par endsync="last" > <audio dur="8s" .../> <video begin="0" dur="10s" end="click" .../></par>...</smil>
This section is informative
Time containers place certain overriding constraints upon the child elements. These constraints can cut short the active duration of any child element.
This section isnormative
All time containers share the basic overriding constraint:
This section is informative
While the child may define a sync relationship that places the begin before 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 simple duration) that extends beyond the end of the parent simple duration, the active duration of the child will be cut short when the parent simple duration ends. Note that this does not imply that the child duration is automatically shortened, or that the parent simple duration is "inherited" by the child.
For example:
<par dur="10s" repeatDur="25s"> <video dur="6s" repeatCount="2" .../> <text begin="5s" dur="indefinite" .../> <audio begin="text1.end" .../></par>
The video will play once for 6 seconds, and then a second time but only for 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 short at the end of the simple duration of thepar. The audio will not show up at all, since it is defined to begin at the end of the active duration of the previous element (thetext element). Since the text element ends when the time container ends, the audio would begin after the time container has ended, and so never is heard. When thepar repeats the first time, everything has happens just as it did the first time. However the last repeat is only a partial repeat (5 seconds), and so only the video will be seen, but it will not be seen to repeat, and the last second of the video will be cut off.
In addition,excl time containers allow only one child to play at once. Subject to thepriorityClass semantics, the active duration of an element may be cut short when another element in the time container begins.
The fill attribute is also used to extend the active duration if it is less than the duration specified in the min attribute.
<par dur="5s"> <img min="7s" dur="4s" fill="freeze".../> </par>
This section is informative
SMIL 1.0 defined constraints on sync-arc definition(e.g., begin="id(image1)(begin)"), allowing references only to qualified siblings. SMIL 2.1 explicitly removes this constraint. SMIL 2.1 also adds event-based timing. Both sync-arcs and event-timing are constrained by the parent time container of the associated element as described above.
This section isnormative
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 a sync-relationshipto the parent (i.e. to an offset from the parent begin).
This section is informative
Note that in particular, an element defined with a sync-arc begin will not automatically 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 timeline was playing. With each repeat of the parent, the sync-arc will be recalculated to yield a begin time relative to the parent time container. See also the sectionResetting element state.
This section isinformative
The specifics for event-based timing are discussed in theEvent Sensitivity section.
This section isnormative
When an element begins, any event-based begin times are cleared. In the following example, if an activate event occurs and then one second later bar ends, then foo begins immediately and the element does not restart four seconds later regardless of the restart setting. However, if an activate event occurs and bar does not end during the next five seconds, the element will restart at the end of that time.
<audio begin="bar.end; activateEvent+5s".../>
See Evaluation of begin and end time lists.
This section isinformative
This section describes what a language designer must actually do to specify the integration of SMIL Timing and Synchronization support into a host language. This includes basic definitions, constraints upon specification, and allowed/supported events.
This section isinformative
The host language designer must define some basic concepts in the context of the particular host language. These provide the basis for timing and presentation semantics.
This section isnormative
application/smil+xml" or "application/smil").This section isnormative
media" argument value to thedurattribute.This section isnormative
This section isnormative
This section is informative
Any XML-based language that integrates SMIL Timing will inherit the basic interfaces defined in DOM[DOM2]. SMIL Timing specifies the interaction of timing functionality and DOM. SMIL Timing also defines constraints upon the basic DOM interfaces. A separate document will define specific DOM interfaces to support SMIL Timing, however this document presumes that there is a mechanism to begin and end elements, and to pause and resume them.
This section isnormative
No syntax support is required to make use of the presumed interfaces, although the "indefinite" argument value on the begin and end attributes can be used to describe timing that will be initiated by DOM methods. In any case, the actions of DOM timing methods will be subject to the constraints of the time model, as described in this document.
A language integrating SMIL Timing and Synchronization need not require a DOM implementation.
If the timing attributes of timed elements are manipulated through DOM interfaces while the timegraph is running, the behavior is not defined by this document. Similarly, if timed elements are inserted into or removed from the document while the timegraph is running, the behavior is not defined. The behavior and any constraints related to this will be specified in a future document.
This section isinformative
SMIL event-timing assumes that the host language supports events, and that the events can be bound in a declarative manner. DOM Level 2 Events[DOM2Events] describes functionality to support this.
This section isnormative
The specific events supported are defined by the host language. If no events are defined by a host language, event-timing is effectively omitted.
This module defines a set of events that may be included by a host language. These include:
If an element is restarted while it is currently playing, the element will raise an endEvent and then abeginEvent, as the element restarts.
In order to make the model operate consistently and remove the effects of synchronization slew in a chain of event times, the timestamp value associated with events such as thebeginEvent, endEvent, andrepeat events is not (necessarily) the actual time that the event is raised, nor is it the time when a time dependent is actually notified of the event. Rather the event timestamp is theearliest time that the eventcould be raised (given the timing model semantics, and assuming that elements would begin and endprecisely when they are defined to). There are three basic cases corresponding to begin and end conditions with zero, positive, and negative offsets respectively:
These examples assume video and audio media that are recorded to be in exact sync with one another.
<par dur="indefinite"> <img end="click" .../> <video begin="foo.endEvent" .../> <audio begin="foo.end" .../></par>
The image "foo" will end when the user clicks on it. The defined time of the end is actually the time of the click event (even if it takes a while to propagate the click event through the presentation mechanism). The "foo" element will raise anendEvent with a timestamp equal to the time of the click event. The behavior in this example is that "bar" and "copy" will be in precise synchronization (although "bar" may actually begin very slightly later, since it can take a while to propagate the events through a system).
<par dur="indefinite"> <img .../> <video begin="foo.click+3s" .../> <audio begin="bar.beginEvent" .../></par>
The video "bar" will begin 3 seconds after the user clicks on "foo". ThebeginEvent for "bar" will have a timestamp equal to the "foo.click" event timestamp plus 3 seconds. The behavior is that in the example above, "bar" and "copy" will be in precise synchronization (although "copy" may actually begin slightly later, since it can take a while to propagate the events through a system).
<par dur="indefinite"> <img .../> <video begin="foo.click-3s" .../> <audio begin="bar.beginEvent" .../></par>
The video "bar" will begin when the user clicks on "foo". The video will begin to play at a 3 second offset into the actual content, because it is defined to begin 3 seconds before the click. However, since "bar" cannot begin any sooner than "now" when the event is raised, it will raise abeginEvent that has the same time as the "foo.click" event. Thus in this case, the audio element "copy" will be precisely three seconds behind (out of sync with) the video.
Additional time model constraints can cause thebeginEvent (orendEvent) event timestamp to differ from the calculated begin (or end) time for an element. For example the element can specify a begin time before the beginning of its parent time container (either with a negative offset value, or with a syncbase time that resolves to a time before the parent begin). In this case, a time dependent of thebegin syncbase time will be defined relative to the calculated begin time. However, the element is constrained to not actually begin before the parent time container. ThebeginEvent will be raised when the element actually begins - in the example case when the parent time container begins. Similarly, theendEventis raised when the element actually ends, which may differ from the calculated end time (e.g. when the end is specified to be after the end of the parent simple duration).
The distinction between syncbase and event times can be useful in certain situations. Consider the following example:
<par> <par begin="5s"> <par begin="-5s"> <img begin="1s; 8s" dur="3s" .../> </par> </par> <img begin="foo.begin" dur="1s" .../> <audio begin="foo.beginEvent" dur="1s" .../></par>
The "foo" element defines two intervals. The inner par cuts off - but does not prune - the first interval, because the innermost par is constrained by the middle par and cannot actually begin until 5s into the document. However the inner par is still synchronized to the document time of 0s. As such, "bar" will play twice: once at 1 second, and again at 8 seconds, because syncbase values use calculated interval times. However the "beep" audio will only play once at 8 seconds which is when "foo" is actually displayed, because intervals that are cut off do not raise events.
While authors are unlikely to author the above example, similar cases can easily arise using syncbase timing. When it is important to distinguish the observed begin time from the scheduled begin time, event-value timing with thebeginEvent orendEvent can be used. However, the author must be aware of the constraints on event-value timing. These include theevent sensitivity constraints, and the fact that many implementations will not optimize scheduling and media preparation for elements with event-value timing as well as for elements with scheduled syncbase-value timing. See also the discussionPropagating changes to times.
This section isnormative
SMIL Timing reserves four DOM methods for controlling the timing of elements:beginElement(),beginElementAt(),endElement(), andendElementAt(), and describes their effect on the timing model. Full definition of these methods is left to a future document describing DOM functionality.
The four DOM methods are used to begin and end the active duration of an element. Authors can (but are not required to) declare the timing to respond to the DOM using the following syntax:
<img begin="indefinite" end="indefinite" .../>ThebeginElement(),beginElementAt(),endElement(), andendElementAt()methods are all subject to time container constraints in much the same way that event-based times are. If any of these methods are called when the parent time container is not active, the methods have no effect.
If a DOM method call is made to begin or end the element (beginElement(),beginElementAt(),endElement() orendElementAt()), each method call creates a single instance time (in the appropriate instance times list). These times are then interpreted as part of the semantics of lists of times, as described inEvaluation of begin and end time lists. These time instances are cleared upon reset just as for event times.
beginElement()orendElement() call is the current presentation time at the time of the DOM method call. beginElementAt() orendElementAt() call is the current presentation time at the time of the DOM method call, plus or minus the specified offset. The offset is measured in parent simple time.beginElement() and beginElementAt()are subject to restart semantics. Refer also to the section Therestart attribute.This section isinformative
The following concepts are the basic terms used to describe the timing model.
A synchronization relationship is defined by the author to express that two or more elements' playback is synchronized.
A time graph is used to represent the temporal relations of elements in a document with SMIL timing. Nodes of the time graph represent elements in the document. Parent nodes can "contain" children, and children have a single parent. Siblings are elements that have a common parent. The links or "arcs" of the time graph represent synchronization relationships between the nodes of the graph.
The time model description uses a set of adjectives to describe particular concepts of timing:
Global time is defined relative to the common reference for all elements, the document root. This is sometimes also referred to asdocument time.
Within a document, when a given element is active or "plays", the contents of that element progress from the beginning of the active duration to the end of the active duration. There will also be a progression from the beginning to the end of each simple duration (the distinction is clearest when the element repeats). It is often convenient to talk about times in terms of a given element's simple duration or its active duration. Generically, this is referred to aslocal time, meaning that times are relative to an element-local reference.
The following terms are used to more precisely qualify local times:
To be meaningful, these terms are described relative to some element. For example, when describing timing semantics,element active time refers to active time for the element under discussion, andparent simple time refers to simple time for that element's parent.
Conversion from global (document) time to an element time, or from one element time to another element time, is described inConverting between local and global times.
When measuring or calculating time, a reference element and the local time form (active, simple or media time) are specified. The measured time or duration is defined in terms of the element time progress. E.g. if the reference element pauses, this may impact the semantics of times or durations measured relative to the element.
Linear media is continuous media that cannot be played in a random-access manner. For example, most Internet streaming video and audio are linear.
Non-linear media can be played in a random access manner. For example, algorithmic animation is non-linear. Discrete media may behave in a non-linear manner.
The linear or non-linear behavior of the media is not a function of the media type, but rather of the renderer or playback engine, and often depends upon the delivery mechanism for the media.
An element is considered to have scheduled timing if the element's start time is given relative to the begin or active end of another element. A scheduled element can be inserted directly into the time graph.
This section isnormative
The start of the interval in which the document is presented is referred to as thedocument begin.
The end of the interval in which the document is presented is referred to as thedocument end.
The difference between the end and the begin is referred to as thedocument duration.
This section isinformative
Begin and active end times in SMIL 2.1 can be specified to be relative to events that are raised in the document playback environment. This supports declarative, interactive timing.Interactive in this sense includes user events such as mouse clicks, events raised by media players like amediaComplete event, and events raised by the presentation engine itself such as apause event.
In scheduled timing, elements are timed relative to other elements. The syncbase for an elementA is the other elementB to which elementA is relative. More precisely, it is the begin or active end of the other element. The syncbase is not simply a scheduled point in time, but rather a point in the time graph.
"Sync-arc" is an abbreviation for "synchronization arc". Sync-arcs are used to relate nodes in the time graph, and define the timing relationship between the nodes. A sync-arc relates an element to its syncbase. The sync-arc may be defined implicitly by context, explicitly by Id-value or event name, or logically with special syntax.
A Clock is a particular timeline reference that can be used for synchronization. A common example that uses real-world local time is referred to aswall-clock timing (e.g. specifying 10:30 local time). Other clocks may also be supported by a given presentation environment.
"Universal Time" (abbreviated UT) is sometimes also referred to as "Greenwich Mean Time" (abbreviated GMT). The two terms are often used loosely to refer to time kept on the Greenwich meridian (longitude zero), five hours ahead of Eastern Standard Time. Times given in UT are almost always given in terms of a 24-hour clock. Thus, 14:42 is 2:42 p.m., and 21:17 is 9:17 p.m.
A hyperlink into or within a timed document may cause a seek of the current presentation time or may activate an element (if it is not in violation of any timing model rules).
During playback, an element may be activated automatically by the progression of time, via a hyperlink, or in response to an event. When an element is activated, playback of the element begins.
SMIL includes support for declaring media, using element syntax defined in"The SMIL Media Object Module". The media that is described by these elements is described as eitherdiscrete orcontinuous:
Time containers group elements together in time. They define common, simple synchronization relationships among the grouped child elements. In addition, time containers constrain the time that children may be active. Several containers are defined, each with specific semantics and constraints on its children.
SMIL timing and synchronization support ultimately controls a set of content or media elements. The content includes things like video and audio, images and vector graphics, as well as text or HTML content. SMIL documents use the SMIL media elements to reference this content. XML and HTML documents that integrate SMIL 2.1 functionality may use SMIL media elements and/or content described by the integrated language (e.g. paragraphs in HTML).
All elements - content/media as well as time containers - support timing markup to describe a begin time and a duration, as well as the ability to play repeatedly. There are several ways to define the begin time. The semantics vary somewhat depending upon an element's time container.
The time model defines two concepts of duration for each element - the simple duration and the active duration. These definitions are closely related to the concept of playing something repeatedly.
The constraints of a parent time container may override the duration of its children. In particular, a child element may not play beyond the simple end of the time container.
The terms for these durations can be modified with theDescriptive Terms for Times, to further distinguish aspects of the time graph.
SMIL 1.0 introduced the notion of synchronization behavior, describing user agent behavior as implementing either "hard synchronization" or "soft synchronization". Using hard sync, the entire presentation would be constrained to the strict description of sync relationships in the time graph. Soft sync allowed for a looser (implementation dependent) performance of the document.
While a document is playing, network congestion and other factors will sometimes interfere with normal playback of media. In a SMIL 1.0 hard sync environment, this will affect the behavior of the entire document. In order to provide greater control to authors, SMIL 2.1 extends the hard and soft sync model to individual elements. This support allows authors to define which elements and time containers must remain in strict or "hard" sync, and which elements and time containers can have a "soft" or slip sync relationship to the parent time container.
See also the section: The syncBehavior, syncTolerance, and syncMaster attributes: controlling runtime synchronization.
The concepts of intervalpruning andcutting off are distinct and should not be confused.
In some cases, after an interval has been created, it must later bepruned (deleted/removed from the timegraph) as more information becomes 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 be removed 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 time containers, a valid interval for a child may not be shown, even though it is otherwise legal with respect to the parent time constraints. These intervals are said to becut off.
For example:
<par begin="-10s" dur="20s"> <img src="slide1.jpg" dur="3s" /> <img src="slide2.jpg" begin="slide1.end+3s" dur="10s" /> <img 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 before its parent time container, and instead will be started at 0s into its parent time synced at 10s into its simple duration. The "slide1" image begins and ends before 10s into the par, and so cannot be shown and iscut off, Intervals that arecut off are not shown and do not raise begin or end events, but still create valid instance times for any syncbase time dependents. Thus, "slide2" will be shown (the interval is from minus 4 seconds to 6 seconds, document time, and so will be shown for 6 seconds, from 0 seconds to 6 seconds), but "note1" will not be shown.
This section is normative.
This section defines the sixteen SMIL 2.1 Timing Modules, which include the BasicInlineTiming module and fifteen other modules that combine to provide full SMIL 2.1 timing support. The separation of the SMIL 2.1 Timing modules is based on the inclusion of the syntactic expression of features using elements, attributes, and attribute values. Including a module in a profile adds both the syntax and associated semantics defined elsewhere in this specification to that profile.
fill=transition is only supported when BasicTransitions or InlineTransitions is included in the language profile. If FillDefault is not included in the profile,fill=default is interpreted the same asfill=auto.fill="transition" is only supported when BasicTransitions or InlineTransitions is included in the language profile. If FillDefault is not included in the profile,fill="default" is interpreted the same asfill="auto".fill=transition is only supported when BasicTransitions or InlineTransitions is included in the language profile.fill=transition is only supported when BasicTransitions or InlineTransitions is included in the language profile. If FillDefault is not included in the profile,fill=default is interpreted the same asfill=auto.This section includes a set of examples that illustrate both the usage of the SMIL syntax, as well as the semantics of specific constructs. This section is informative.
Note: In the examples below, the additional syntax related to layout and other issues specific to individual document types is omitted for simplicity.
All the children of apar begin by default when thepar begins. For example:
<par> <img dur="5s" src="img.jpg" /> <img dur="10s" src="img2.jpg" /> <img begin="2s" dur="5s" src="img3.jpg" /></par>
Elements "i1" and "i2" both begin immediately when thepar begins, which is the default begin time. The active duration of "i1" ends at 5 seconds into thepar. The active duration of "i2" ends at 10 seconds into thepar. The last element "i3" begins at 2 seconds since it has an explicit begin offset, and has a duration of 5 seconds which means its active duration ends 7 seconds after thepar begins.
Each child of aseq begins by default when the previous element ends. For example:
<seq> <img begin="0s" dur="5s" src="img1.jpg" /> <img dur="10s" src="img2.jpg" /> <img begin="1s" dur="5s" src="img3.jpg" /></seq>
The element "i1" begins immediately, with the start of theseq, and ends 5 seconds later. Note: specifying a begin time of 0 seconds is optional since the default begin offset is always 0 seconds. The second element "i2" begins, by default, 0 seconds after the previous element "i1" ends, which is 5 seconds into theseq. Element "i2" ends 10 seconds later, at 15 seconds into theseq. The last element, "i3", has a begin offset of 1 second specified, so it begins 1 second after the previous element "i2" ends, and has a duration of 5 seconds, so it ends at 21 seconds into theseq.
<par> <excl> <par> ... </par> <par> ... </par> </excl> <a href="p1"><img src="Button1.jpg"/></a> <a href="p2"><img src="Button2.jpg"/></a></par>
This example models jukebox-like behavior. Activating the first image hyperlink activates the media items of parallel container "p1". If the link on the second image is traversed, "p2" is started (thereby deactivating "p1" if it would still be active) from time 0.
<smil ...>...<par> <excl> <par begin="btn1.activateEvent"> ... </par> <par begin="btn2.activateEvent"> ... </par> </excl> <img src=... /> <img src=... /></par>...<smil>
The same jukebox example, using event-based activation.
<excl> <ref begin="0s" ... /> <ref begin="5s" ... /></excl>
In the example above, the beginning of "b" deactivates "a" (assuming that a is still active after 5 seconds). Note that this could also be modeled using a sequence with an explicit duration on the children. While the scheduled syntax is allowed, this is not expected to be a common use-case scenario.
For simple media elements (i.e., media elements that are not time containers) that reference discrete media, the implicit duration is defined to be 0. This can lead to surprising results, as in this example:
<seq> <img src="img1.jpg" /> <video src="vid2.mpg" /> <video src="vid3.mpg" /></seq>
The implicit syncbase of a sequence is defined to be the effective active end of the previous element in the sequence. In the example, the implicit duration of the image is used to define the simple and active durations. As a result, the default begin of the second element causes it to begin at the same time as the image. Thus, the image will not show at all! Authors will generally specify an explicit duration for any discrete media elements.
There is an important difference between the semantics of end and dur. The dur attribute, in conjunction with the begin time, specifies the simple duration for an element.
This is the duration that is repeated when the element also has a repeat behavior specified. The attribute end on the other hand overrides the active duration of the element. If the element does not have repeat behavior specified, the active duration is the same as the simple duration. However, if the element has a repeat behavior specified, then the end will override the repeat, but will not affect the simple duration. For example:
<html ...>...<seq repeatCount="10" end="stopBtn.click"> <img src="img1.jpg" dur="2s" /> <img src="img2.jpg" dur="2s" /> <img src="img3.jpg" dur="2s" /></seq>...</html>
The sequence will play for 6 seconds on each repeat iteration. It will play through 10 times, unless the user clicks on a "stopBtn" element before 60 seconds have elapsed.
When an implementation supports the DOM methods described in this document, it will be possible to make an element begin or end the active duration using script or some other browser extension. When an author wishes to describe an element as interactive in this manner, the following syntax can be used:
<audio src="song1.au" begin="indefinite" />
The element will not begin until thebeginElement() method is called.
SMIL 1.0 defines the model for timing, including markup to define element timing, and elements to define parallel and sequence time containers. This version introduces some syntax variations and additional functionality, including:
The complete syntax is described here, including syntax that is unchanged from SMIL 1.0.
A significant motivation for SMIL 2.1 is the desire to integrate declarative, determinate scheduling with interactive, indeterminate scheduling. The goal is to provide a common, consistent model and a simple syntax.
Note that "interactive" content does not refer simply to hypermedia with support for linking between documents, but specifically to content within a presentation (i.e. a document) that isactivated by some interactive mechanism (often user-input events, but including local hyperlinking as well).
SMIL 2.1 describes extensions to SMIL 1.0 to support interactive timing of elements. These extensions allow the author to specify that an element should begin or end in response to an event (such as a user-input event like "activateEvent" or "click"), or to a hyperlink activation, or to a DOM method call.
The syntax to describe this usesevent-value specifications and the special argument value "indefinite" for thebegin andend attribute values. Event values describe user interface and other events. If an element should only begin (or end) with a DOM method call, thebegin andend attributes allow the special value "indefinite" to indicate this. Settingbegin="indefinite" can also be used when a hyperlink will be used to begin the element. The element will begin when the hyperlink is actuated (usually by the user clicking on the anchor). It is not possible to control the active end of an element using hyperlinks.
SMIL 2.1 represents an evolution from earlier multimedia runtimes. These were typically either pure, static schedulers or pure event-based systems. Scheduler models present a linear timeline that integrates both discrete and continuous media. Scheduler models tend to be good for storytelling, but have limited support for user-interaction. Event-based systems, on the other hand, model multimedia as a graph of event bindings. Event-based systems provide flexible support for user-interaction, but generally have poor scheduling facilities; they are best applied to highly interactive and experiential multimedia.
The SMIL 1.0 model is primarily a scheduling model, but with some flexibility to support continuous media with unknown duration. User interaction is supported in the form of timed hyperlinking semantics, but there was no support for activating individual elements via interaction.
To integrate interactive content into SMIL timing, the SMIL 1.0 scheduler model is extended to support several new concepts:indeterminate timing andevent-activation.
Withindeterminate timing, an element has an undefinedbegin orend time. The element still exists within the constraints of the document, but thebegin orend time is determined by some externalactivation. Activation may be event-based (such as by a user-input event), hyperlink based (with a hyperlink targeted at the element), or DOM based (by a call to thebeginElement() orbeginElementAt() methods). From a scheduling perspective, the time is described asunresolved.
The event-activation support provides a means of associating an event with thebegin orend time for an element. When the event is raised (e.g. when the user clicks on something), the associated time isresolved to adeterminate time. The actualbegin orend time is computed as the time the event is raised plus or minus any specified offset.
The computed time defines the synchronization for the element relative to the parent time container. It is possible for the computedbegin orend time to occur in the past, e.g. when a negative offset value is specified, or if there is any appreciable delay between the time the event is raised and when it is handled by the SMIL implementation. See also the sectionHandling negative offsets for begin.
Note that an event basedend will not be activated until the element has already begun. Any specifiedend event is ignored before the element begins.
The constraints imposed on an element by its time container are an important aspect of the event-activation model. In particular, when a time container is itself inactive (e.g. before it begins or after it ends), no events are handled by the children. If the time container is frozen, no events are handled by the children. No event-activation takes place unless the time container of an element is active. For example:
<smil ...>...<par begin="10s" dur="5s"> <audio src="song1.au" begin="btn1.activateEvent" /></par>...</smil>
If the user activates (e.g., clicks on) the "btn1" element before 10 seconds, or after 15 seconds, the audio element will not play. In addition, if the audio element begins but would extend beyond the specified active end of thepar container, it is effectively cut off by the active end of thepar container.
See also the discussion of Event sensitivity.