This section is normative.

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in [RFC2119].

For readability, these words do not appear in all uppercase letters in this specification.

This section is normative.

SMIL functionality is partitioned into 12 functional areas. Within each functional area a further partitioning is applied into modules. All of these modules, and only these modules, are associated with the SMIL namespace.

The functional areas and their corresponding modules are:

Note: Modules marked with (**) are new Modules added in SMIL 3.0. Modules marked with (*) are revised modules from SMIL 2.1.

1. Animation
   1. BasicAnimation
   2. SplineAnimation
2. Content Control
   1. BasicContentControl
   2. CustomTestAttributes
   3. PrefetchControl
   4. RequiredContentControl (**)
   5. SkipContentControl
3. Layout
   1. AlignmentLayout
   2. AudioLayout
   3. BackgroundTilingLayout
   4. BasicLayout (*)
   5. MultiWindowLayout
   6. OverrideLayout
   7. StructureLayout (**)
   8. SubRegionLayout
4. Linking
   1. BasicLinking
   2. LinkingAttributes
   3. ObjectLinking
5. Media Objects
   1. BasicMedia
   2. BrushMedia
   3. MediaAccessibility
   4. MediaClipping
   5. MediaClipMarkers
   6. MediaDescription
   7. MediaOpacity (**)
   8. MediaPanZoom (**)
   9. MediaParam (*)
   10. MediaRenderAttributes(**)
6. SmilText
   1. BasicText (**)
   2. TextStyling(**)
   3. TextMotion (**)
7. Metainformation
   1. Metainformation (*)
8. Structure
   1. Structure
   2. Identity (**)
9. Timing
   1. AccessKeyTiming
   2. BasicInlineTiming
   3. BasicTimeContainers
   4. BasicExclTimeContainers
   5. BasicPriorityClassContainers
   6. DOMTimingMethods (**)
   7. EventTiming
   8. FillDefault
   9. MediaMarkerTiming
   10. MinMaxTiming
   11. MultiArcTiming
   12. RepeatTiming
   13. RepeatValueTiming
   14. RestartDefault
   15. RestartTiming
   16. SyncbaseTiming
   17. SyncBehavior
   18. SyncBehaviorDefault
   19. SyncMaster
   20. TimeContainerAttributes
   21. WallclockTiming
10. Time Manipulations
    1. TimeManipulations
11. State
    1. StateTest (**)
    2. UserState (**)
    3. StateSubmission (**)
    4. StateInterpolation (**)
12. Transitions
    1. BasicTransitions
    2. InlineTransitions
    3. TransitionModifiers
    4. FullScreenTransitionEffects

Each of these modules introduces a set of semantically-related elements, properties, and attributes. Each functional area has a corresponding section in this specification document. Further details on each of the modules is specified within those sections.

The modules may be independent or complementary. For example, the SyncMaster module requires and builds upon the SyncBehavior module, but the PrefetchControl and SkipContentControl modules are independent from each other. In addition, some modules require modules from other functional areas.

Modules specify their integration requirements. When one module requires another module for basic features and as a prerequisite for integration, a profile must include the second module in order to include the first. The first module is said to be a dependent of the second module. Dependency may be nested, in that a module may be dependent on a module that is a dependent itself.

Table 1 presents the SMIL 3.0 modules and the modules they depend on.

This section is normative.

This section specifies the identifiers for the SMIL 3.0 MIME Type and the SMIL 3.0 modules. The identifiers for SMIL 3.0 profiles are defined as part of the profile specification.

2.5.1 The SMIL Mime Type

Documents authored in host-language conformant profiles may be associated with the "application/smil+xml" mime type: "application/smil+xml" mime type are required to be host language conformant. The "application/smil" mime type as specified in SMIL 2.0 [SMIL20] is obsolete.

2.5.2 Identifiers for SMIL 3.0 Modules

Each module in this specification has a unique identifier associated with it. They are intended to uniquely and consistently identify each of them. They should be used as values in a test for whether an implementation includes a specific module, as well as in other circumstances where a need to refer to a specific SMIL 3.0 module is necessary. These identifiers are to be used with the systemRequired attribute from the RequiredContentControl module.

Table 2 summarizes the identifiers for SMIL 3.0 modules.

2.5.3 Identifiers for SMIL 3.0 Profiles and Features

This section is normative.

The rules for host-language and SMIL 3.0 document conformance, as well as the rules for SMIL 3.0 User Agent conformance are provided as part of the SMIL Scalability Framework.

This section is normative

3.3.1 Elements and attributes

This section defines the elements and attributes that make up the SMIL 3.0 Structure module.

The smil element

The smil element acts as the root element for all SMIL Host Language conformant language profiles.

Element content

The smil element may contain the following elements:

head

body

The head element

The head element contains information that is not related to the temporal behavior of the presentation. Three types of information may be contained by head. These are meta information, layout information, and author-defined content control.

Element content

The head element contains elements depending on the other modules and specific syntax included in the language profile integrating this module.

The body element

The body element contains information that is related to the temporal and linking behavior of the document. It acts as the root element of the timing tree.

The body element has the timing semantics of a time container equal to that of the seq element [BasicTimeContainers module]. Note, that in other language profiles, where a body element from another (Structure) Module is in use, that body element may have different timing semantics. For example, in the XHTML+SMIL language profile (still in progress and not yet a W3C Recommendation), the body element comes from HTML, and acts as a par time container.

The timing attributes defined in the various SMIL 3.0 Timing modules are part of the body element so far as the corresponding timing modules, such as BasicInlineTiming, are part of the language profile. When a timing module is included in a language profile, the features of that module should be supported on the body element just as they are supported on the other elements in the profile. For example, the syncMaster attribute should be supported on the body element if the SyncMaster module is included in the integrating profile.

Element content

The body element contains elements depending on the other modules and specific syntax included in the language profile integrating this module.

This section is normative

When this module is included in a language profile, the xml:id, class, and title attributes defined in this module must be included on all elements from all modules used in the profile, including those from other module families and of non-SMIL origin. The integrating profile should also consider adding the xml:lang attribute to the applicable elements.

The SMIL Structure module is the starting module when building any SMIL Host Language conformant language profile. The Structure module may not be used for building other, non-SMIL Host Language conformant language profiles. This implies that the SMIL Structure module must at least be accompanied with the other modules mandatory for SMIL Host language conformance, and the elements in the structure module must include at least the minimum content models required for SMIL Host language conformance.

When modules from outside the SMIL 3.0 namespace are integrated in the language profile, it must be specified how the elements from those non-SMIL modules fit into the content model of the used SMIL modules (and vice versa). For example, with respect to the SMIL Structure module, the Profiling Entities in the DTD should be overridden. This creates a so-called hybrid document type [XMOD]. In case of a so-called compound document type, the rules of XML namespaces must be satisfied [XML-NS].

This section is normative

3.5.1 SMIL 3.0 Identity Module Overview

This module contains two attributes, version and baseProfile, which are used to identify which version of SMIL and for which Profile the document is written for.

3.5.2 Elements and attributes

Element definition

The Identity Module does not contain any element definitions.

<smil xml:id="root" xmlns="http://www.w3.org/ns/SMIL" version="3.0" baseProfile="Tiny" >
  <head xml:id="head"> ...   </head>
  <body xml:id="body"> ...   </body>
</smil>

3.5.3 Integration Requirements for the SMIL 3.0 Identity Module

It is the responsibility of the language profile to specify which elements support the version and baseProfile attributes. All profiles should at least support these two attributes on the top-level smil element.

This section is normative.

This section provides convenience definitions for common timing and resource identifier terms used in this module.

SMIL provides a number of timing-related concepts that are used to determine activation, duration and termination of media objects in a presentation. The temporal semantics of these concepts are discussed in the SMIL 3.0 Timing and Synchronization module.

Intrinsic Duration

The duration of a referenced media item based on the temporal properties of that item (defined next), without any explicit SMIL timing markup. Some media objects have a well-defined notion of implicit duration (such as a 7 second audio clip), while other objects do not have well-defined durations (such as a string of plain text). In SMIL, the implicit duration for any media object that does not have a well-defined duration is set to be zero seconds. The implicit duration is used to calculate scheduling information; it is sometimes independent of the actual duration of a media object (such as with a live media stream or with an image with multiple internal frames when no particular duration can be derived by the SMIL scheduler). From a scheduling perspective, an object's intrinsic duration forms the basis for the simple duration of the object during presentation. This duration may be shortened or extended using SMIL timing markup.

Continuous Media

Media objects, such as stored audio or video files, for which there is a measurable and well-understood duration. For example, a five second audio clip is continuous media, because it has a well-understood duration of five seconds. Opposite of "discrete media". See also the definition of continuous media in the Timing module.

Discrete Media

Media objects, such as images or non-timed text data, that has no obvious duration. For example, a JPEG image is generally considered discrete media, because there's nothing in the file indicating how long the JPEG should be displayed. Opposite of "continuous media". See also the definition of discrete media in the Timing module.

The distinction between continuous and discrete media is sometimes arbitrary and may be SMIL renderer dependent. For example, animated images that do not have a well-defined duration (simply a repeating collection of frames) are classified for SMIL scheduling purposes as being discrete media; such objects have an intrinsic scheduling duration of zero seconds.

In this specification, the term URI [URI] refers to a universal resource identifier, as defined in [RFC3986] and subsequently extended under the name IRI in [RFC3987]. In some cases, the term URI has been retained in the specification to avoid using new names for concepts such as "Base URI" that are defined or referenced across a whole family of XML specifications.

This section is normative.

This module defines the baseline media functionality of a SMIL player.

4.4.1 Media Object Elements - ref, and its synonyms animation, audio, img, text, textstream and video

SMIL defines a single generic media object element that allows the inclusion of external media objects into a SMIL presentation. Media objects are included by reference (using a IRI).

ref

Generic media reference

In addition to the ref element, SMIL allows the use of the following set of synonyms:

animation

Animated vector graphics or other animated format

audio

Audio clip

img

Still image, such as PNG or JPEG

text

External text reference

textstream

A text document that includes timing information for the purpose of time-dependent rendering of portions of the text document.

video

Video clip

All of these media elements are semantically identical. When playing back an external media object, the player must not derive the exact type of the media object from the name of the media object element. Instead, it must rely solely on other sources about the type, such as the type information communicated by a server or the operating system, or by using type information contained in the type attribute.

Anchors and links may be attached to visual media objects, i.e. media objects rendered on a visual abstract rendering surface.

Element Content

Languages utilizing the SMIL BasicMedia module must define the complete set of elements which may act as children of media object elements. There are currently no required children of a media object defined in the BasicMedia Module, but languages utilizing the BasicMedia module may impose requirements beyond this specification.

4.4.2 Integration Requirements

If the including profile supports the XMLBase functionality [XMLBase] , the values of the src and longdesc attributes on the media object elements must be interpreted in the context of the relevant XMLBase URI prefix.

User-agent implementations are responsible for defining the rendering behavior when fragment addressing is used in the src attribute. Such definition should be added to language profiles that wish to include specific media addressing features. For example:
- User-agents should define the default behavior for when referencing a non-existing id in the target media document.
- User-agents should define the rendering method for the selected media fragment: in context, with or without highlighting and scrolling, or stand-alone (selective rendering only).
- User-agents should describe the timing implication for when addressing timed-content.

SMIL 3.0 allows but does not require user agents to be able to process XPointer values in the IRI value of the src attribute. The SMIL 3.0 Linking Module provides additional information related to XPointer.

This section is normative.

This section defines the elements and attributes that make up the SMIL MediaParam Module definition. The MediaParam module is intended to provide a uniform mechanism for media object initialization. Languages implementing elements and attributes found in the MediaParam module must implement all elements and attributes defined below, as well as BasicMedia.

4.5.1 The param element

The param element allows a general parameter value to be sent to a media object renderer as a name/value pair. This parameter is sent to the renderer at the time that the media object is processed by the scheduler. It is up to the media renderer to associate an action with the given param. The media renderer may choose to ignore any unknown or inappropriate param values (such as sending a font size to an audio object).

Any number of param elements may appear (in any order) in the content of a media object element or in a paramGroup element. If a given parameter is defined multiple times, the lexically last version of that parameter value should be used.

The syntax of names and values is assumed to be understood by the object's implementation. The SMIL specification does not specify how user agents should retrieve name/value pairs.

Example

<ref src="http://www.example.com/herbert.face">
  <param name="mood" value="surly" valuetype="data"/>
  <param name="accessories" value="baseball-cap,nose-ring" valuetype="data"/>
</ref>

4.5.2 The paramGroup element

The paramGroup element provides a convenience mechanism for defining a collection of media parameters that may be reused with several different media objects. If present, the paramGroup element must appear in the head section of the document. The content of the paramGroup element consists of zero or more param elements. The paramGroup element may not contain nested paramGroup element definitions.

Examples

<smil ... >
  <head>
    ...
    <paramGroup xml:id="clown">
       <param name="mood" value="upBeat" valuetype="data"/>
       <param name="accessories" value="flowers,dunceCap"/>
    </paramGroup>
    ...
  </head>
  <body>
    ...
    <ref src="http://www.example.com/andy.face" paramGroup="clown"/>
    ...
    <ref src="http://www.example.com/sally.face" paramGroup="clown"/>
    ...
  </body>
</smil>

<smil ... >
  <head>
    ...
    <paramGroup xml:id="clown">
       <param name="mood" value="upBeat" valuetype="data"/>
       <param name="accessories" value="flowers,dunceCap"/>
    </paramGroup>
    ...
  </head>
  <body>
    ...
    <ref src="http://www.example.com/andy.face" paramGroup="clown">
      <param name="gender" value="male"/>
    </ref>
    ...
  </body>
</smil>

<smil ... >
  <head>
    ...
    <paramGroup xml:id="clown">
       <param name="mood" value="upBeat" valuetype="data"/>
       <param name="accessories" value="flowers,dunceCap"/>
    </paramGroup>
    ...
  </head>
  <body>
    ...
    <ref src="http://www.example.com/andy.face" paramGroup="clown">
      <param name="gender" value="male"/>
      <param name="mood" value="depressed" valuetype="data"/>
    </ref>
    ...
  </body>
</smil>

4.5.3 Element Attributes for Media Object Initialization

In addition to the element attributes defined in BasicMedia, media object elements and layout regions may add the media initialization attribute defined below.

4.5.4 Integration Requirements

Any profile that integrates the functionality of this module is strongly encouraged to define a set of common parameter names that may be used to initialize common media object types for that profile. This can significantly increase interoperability of user agents and media rendering libraries.

The supported uses of the type and valuetype attributes on the param element must be specified by the integrating profile. If a profile does not specify this, the type and valuetype attributes will be ignored in that profile.

This section is normative.

This section defines the elements and attributes that make up the SMIL MediaRenderAttributes Module definition. Languages implementing elements and attributes found in the MediaRenderAttributes module must implement all elements and attributes defined below, as well as BasicMedia.

4.6.1 Elements

This module does not define any elements.

4.6.2 Element Rendering Attributes for All Media Objects

In addition to the element attributes defined in BasicMedia, media object elements and layout regions may have the attributes and attribute extensions defined below.

4.6.3 Integration Requirements

Any profile that supports the erase attribute must define what is meant by "display area" and further define the interaction. See the definition of erase for more details.

This section is normative.

This section defines the elements and attributes that make up the SMIL MediaOpacity Module definition. Languages implementing elements and attributes found in the MediaOpacity module must implement all elements and attributes defined below, as well as BasicMedia.

4.7.1 Elements

This module does not define any elements.

4.7.2 Element Attributes for All Media Objects

In addition to the element attributes defined in BasicMedia, media object elements and layout regions may have the attributes and attribute extensions defined below.

4.7.3 Integration Requirements

This module does not introduce any special integration constraints.

This section is normative.

This section defines the attributes that make up the SMIL MediaClipping Module definition. Languages implementing the attributes found in the MediaClipping module must implement the attributes defined below, as well as BasicMedia.

4.8.1 MediaClipping Attributes

This section is normative.

This section defines the attribute extensions that make up the SMIL MediaClipMarkers Module definition. Languages implementing elements and attributes found in the MediaClipMarkers module must implement all elements and attributes defined below, as well as BasicMedia and MediaClipping.

4.9.1 MediaClipMarkers Attribute Extensions

This section defines the elements and attributes that make up the SMIL BrushMedia Module definition. Languages implementing elements and attributes found in the BrushMedia module must implement all elements and attributes defined below.

4.10.1 The brush element

The brush element is a lightweight media object element which allows an author to paint a solid color in place of a media object. Attributes associated with media objects may also be applied to brush element. (A specific profile will determine the attribute set applied to this element.)

4.10.2 Integration Requirements

Profiles including the BrushMedia module must provide semantics for using a color attribute value of inherit on the brush element. Because inherit doesn't make sense in all contexts, the value of inherit is prohibited on the color attribute of the brush element for profiles that do not otherwise define these semantics.

This section is normative.

This section defines the elements and attributes that make up the SMIL MediaAccessibility Module definition. Languages implementing elements and attributes found in the MediaAccessibility module must implement all elements and attributes defined below, as well as MediaDescription.

4.11.1 MediaAccessibility Attributes

This section is normative.

This section defines the elements and attributes that make up the SMIL MediaDescription Module definition. Languages implementing elements and attributes found in the MediaDescription module must implement all elements and attributes defined below.

4.12.1 MediaDescription Attributes

This section is normative.

4.13.1 Overview

4.13.2 Elements and Attributes for the MediaPanZoom Module

This module does not define any new elements. It provides extensions to the ref element (and its synonyms), and to the region element.

The ref Element

The panZoom attribute is added to media object references.

Element content

The SMIL MediaPanZoom module does not extend the content model for the ref element integrating these attributes.

The region Element

The panZoom attribute is added to regions definitions.

Element content

The SMIL MediaPanZoom module does not extend the content model for the region element integrating these attributes.

Attribute Examples

This section is informative.

Assume the following SMIL example:

<smil ...>
  <head>
  ...
    <layout>
      <root-layout height="200" width="300" backgroundColor="red" />
      <region xml:id="I" top="0" left="0" height="200" width="300"  backgroundColor="blue" />
    </layout>
  </head>
  <body>
    <seq> 
      <ref xml:id="R1" src="table.jpg" panZoom="0,0,300,200" dur="5s" region="I" />
      <ref xml:id="R2" src="table.jpg" panZoom="80,50,160,125" dur="5s" region="I" fit="meet"/>
      <ref xml:id="R3" src="table.jpg" panZoom="80,50,160,125" dur="5s" region="I" fit="meetBest"/>
      <ref xml:id="R4" src="table.jpg" panZoom="240,120,85,110" dur="5s" region="I" fit="meet"/>
    </seq>
  </body>
</smil>

In this example, a single region is defined that is used to display four instances of the same image. Each media reference within the sequence S contains a different panZoom area definition, each of which will result in the following behavior:

1. The media reference R1 defines a panZoom area that encompasses the entire media object space; the full image will be shown in region I, as is shown in the following image:
   
   Note that the origin of the image is aligned with the origin of the media object, at the top-left of the region.
2. The media reference R2 defines a panZoom area that encompasses the center portion of the media object space. The projection of the media into region I will result in a zoom into the source image, as is shown in the following image:
   
   

   Note that the origin of the sub-image defined by the panZoom area is placed at the origin of the top-left of the region. Note also that the value of the fit attribute determines that the image is scaled (while maintaining the aspect ratio), resulting in the zoom effect.

3. The media reference R3 defines a panZoom area that is the same as in reference R2; the difference in this example is that the value of the fit attribute does not permit enlargement of the source image into the region. As a result, the image is placed at top-left in an unscaled rendering:
   
   
4. The media reference R4 defines a panZoom area that extends beyond the boundaries of the media object. When it is projected into the region I with a fit value that scales the image with preserved aspect ratio, the entire extent of the panZoom area is scaled: the areas that extend beyond the image content are rendered as (scaled) transparent content:
   
   

All of the previous examples illustrate how a panZoom area operates on a media object that contains a media-defined viewable extent. The panZoom attribute may also be applied to visual objects that do not have predefined extents. Consider the following example, in which an unstructured text object is placed in a region:

<smil ...>
  <head>
  ...
    <layout>
      <root-layout height="200" width="300" backgroundColor="red" />
      <region xml:id="T" top="0" left="0" height="50" width="300"  backgroundColor="blue" />
    </layout>
  </head>
  <body>
    <seq> 
      <ref xml:id="R0" src="short_story.txt" panZoom="0,10,50,200" dur="10s" region="T" />
    </seq>
  </body>
</smil>

In this example, a single region is defined that is used to display a undimensioned text object. In SMIL 3.0, the text object would first be rendered to an off-screen bitmap based on the default settings for the media object (font, font size, font color) and then a panZoom area of the defined size would be overlaid on this text representation. This facility is especially useful when combined with SMIL Animation, as discussed in the next example.

The ability to define a panZoom area, when combined with SMIL animation primitives, provides a simple mechanism for doing pan/zoom animations over a visual object. (These pan/zoom animations are often called 'Ken Burns' animations.) The following example illustrates how a pan window may be positioned and moved over an image area:

<smil ...>
  <head>
  ...
    <layout>
      <root-layout height="200" width="300" backgroundColor="red" />
      <region xml:id="B" top="0" left="0" height="50" width="75"  backgroundColor="blue" />
    </layout>
  </head>
  <body>
    <seq> 
      <ref xml:id="R0" src="table_233x150.jpg" panZoom="0,0,50,75" dur="20s" region="B" fit="meet" >
         <animate attributeName="panZoom" 
                     values="25,20,50,75; 45,55,50,75; 140,40,50,75; 35,0,100,150; 0,0,100,150" 
                     dur="20s" />
      </ref>
      ...
    </seq>
  </body>
</smil>

In this example, an image with intrinsic size of 233x150 pixels is rendered into a region of size 50x75. An initial panZoom area is defined that displays a 50x75 portion of that image, positioned in its top-left corner. During the following 20 seconds, the panZoom area is moved across the image according to the behavior of the animate element; the panZoom area changes are scheduled at equal points across the animation timeline (in this case, every 5 seconds). During the final animation, the panZoom area is extended to implement a zoom-out across the entire image. An illustration of the rendering results is shown below:

4.13.3 MediaPanZoom Module Events

This module does not define any SMIL events.

4.13.4 SMIL MediaPanZoom Implementation and Integration

Implementation Details

The MediaPanZoom module allows individual media object references to override the default values for certain attributes. In all cases, the attributes will apply only to the (sub-)region referenced by the media object. Changes will not propagate to child sub-regions or to parent regions.

Integration Requirements

The functionality in this module builds on top of the functionality in the Media module, which is a required prerequisite for inclusion of the MediaPanZoom module.

Differences with the SVG viewBox Attribute

The functionality in this module builds on the viewBox definition of SVG. Unlike SVG, the SMIL panZoom attribute defines a logical sub-image that contains only content within the panZoom area; SVG uses the viewBox to define a minimum viewing dimension for content, but allowing content outside the viewBox to be displayed in the region.

The MediaPanZoom module does not define a preserveAspectRatio attribute, since this functionality is already provided by the SMIL fit and registration/alignment attributes.

4.13.5 Document Type Definition (DTD) for the MediaPanZoom Module

See the full DTD for the SMIL Layout modules.

This section is normative

5.4.1 Changes for SMIL 3.0

5.4.2 Overview

5.4.3 Attributes

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

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

The begin and dur attributes: basic timing support

The normative syntax rules for each attribute value variant are described in Timing attribute value grammars; an attribute value syntax summary is provided here as an aid to the reader.

Begin value semantics

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

Handling negative offsets for begin

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

The computed begin time defines the scheduled synchronization relationship of the element, even if it is not possible to begin the element at the computed time. The time model uses the computed begin time, and not the observed time of the element begin.

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

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

The element will actually begin at the time computed according to the following algorithm:

Let o be the offset value of a given begin value,
d be the associated simple duration, 
AD be the associated active duration.
Let rAt be the time when the begin time becomes resolved.
Let rTo be the resolved sync-base or event-base time without the offset
Let rD be rTo - rAt.  If rD < 0 then rD is set to 0.
 
If AD is indefinite, it compares greater than any value of o or ABS(o).
REM( x, y ) is defined as x - (y * floor( x/y )). 
If y is indefinite or unresolved, REM( x, y ) is just x.

Let mb = REM( ABS(o), d ) - rD

If ABS(o) >= AD then the element does not begin.
Else if mb >= 0 then the media begins at mb.
Else the media begins at mb + d.

If the element repeats, the Iteration value of the repeat event has the calculated value based upon the above computed begin time, and not the observed number of repeats.

<smil ...> 
...
<ref begin="foo.activateEvent-8s" dur="3s" repeatCount="10" .../>
...
</smil>

Negative begin delays

The presentation effect for the element (e.g. the display of visual media) is equivalent to that for a clipBegin value (with the same magnitude) for the first -- and only the first -- iteration of a repeated element. If no repeat behavior is specified, the element presentation effect of a negative begin offset is equivalent to a clipBegin specification with the same magnitude as the offset value. Nevertheless, the timing side effects are not equivalent to a clipBegin value as described. Time dependents of the begin value will behave as though the element had begun earlier.

Dur value semantics

The length of the simple duration is specified using the dur attribute. The dur attribute syntax is described below.

If there is any error in the argument value syntax for dur, the attribute will be ignored (as though it were not specified).

If the "media" attribute value is used on an element that does not define media (e.g. on the SMIL 3.0 time container elements par, seq and excl), the attribute will be ignored (as though it were not specified). Contained media such as the children of a par are not considered media directly associated with the element.

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

• For simple media elements that specify continuous media (i.e. media with an inherent notion of time), the implicit duration is the intrinsic duration of the media itself - e.g. video and audio files have a defined duration.

  This comment is informative.

  Note that clipBegin and clipEnd attributes on a media element may override the intrinsic media duration, and will define the implicit duration. See also the Media Object module.
• For simple media elements that specify discrete media (some times referred to as "static" media), the implicit duration is defined to be 0.

• This comment is informative.

  For par, seq and excl time containers, and media elements that are also time containers, the implicit simple duration is a function of the type of the time container and of its endsync attribute. For details see the section Time container durations.

If the author specifies a value for dur that is shorter than the implicit duration for an element, the implicit duration will be cut short by the specified simple duration.

If the author specifies a simple duration that is longer than the implicit duration for an element, the implicit duration of the element is extended to the specified simple duration:

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

Examples

<par>
   <audio src="song1.au" begin="5s" dur="4s" />
</par>

<par>
   <audio xml:id="song1" src="song1.au" />
   <img src="img1.jpg" begin="song1.begin+2s" />
</par>

<smil ...>
...
<text xml:id="show" ... />
<img begin="show.activateEvent" dur="3.5s" ... />
...
</smil>

The end attribute: controlling active duration

SMIL 3.0 provides an additional control over the active duration. The end attribute allows the author to constrain the active duration by specifying an end value using a simple offset, a time base, an event-base, a syncbase, or DOM methods calls. The rules for combining the attributes to compute the active duration are presented in the section, Computing the active duration.

The normative syntax rules for each attribute value variant are described in the section Timing attribute value grammars; a syntax summary is provided here as an aid to the reader.

If the end value becomes resolved while the element is still active, and the resolved time is in the past, the element should end the active duration immediately. Time dependents defined relative to the end of this element should be resolved using the computed active end (which may be in the past), and not the observed active end.

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

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

<video end="10s" src="8-SecondVideo.mpg" .../>

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

<audio src="foo.au" dur="2s" repeatDur="10s" 
       end="foo.end" .../>

<par>
   <audio src="music.au" dur="20s" end="10s" ... />
</par>

<smil ...>
...
<par>
<audio src="music.au" begin="gobtn.activateEvent" repeatDur="indefinite"
          end="30s" ... />
     <img src="foo.jpg" dur="40s" ... />
</par>
...
</smil>

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

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

Handling negative offsets for end

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

The min and max attributes: more control over the active duration

The min/max attributes provide the author with a way to control the lower and upper bound of the element active duration.

If there is any error in the argument value syntax for min, the attribute will be ignored (as though it were not specified).

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

If there is any error in the argument value syntax for max, the attribute will be ignored (as though it were not specified).

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

If the "media" argument value is specified for either min or max on an element that does not define media (e.g. on the SMIL 3.0 time container elements par, seq and excl), the respective attribute will be ignored (as though it were not specified). Contained media such as the children of a par are not considered media directly associated with the element.

If both min and max attributes are specified then the max value must be greater than or equal to the min value. If this requirement is not fulfilled then both attributes are ignored.

The rule to apply to compute the active duration of an element with min or max specified is the following: Each time the active duration of an element is computed (i.e. for each interval of the element if it begins more than once), this computation is made without taking into account the min and max attributes (by applying the algorithm described in Computing the active duration). The result of this step is checked against the min and max bounds. If the result is within the bounds, this first computed value is correct. Otherwise two situations may occur:

• if the first computed duration is greater than the max value, the active duration of the element is defined to be equal to the max value (see the first example below).

• if the first computed duration is less than the min value, the active duration of the element becomes equal to the min value and the behavior of the element is as follows :

  • if the repeating duration (or the simple duration if the element doesn't repeat) of the element is greater than min then the element is played normally for the (min constrained) active duration. (see the second and third examples below).

  • otherwise the element is played normally for its repeating duration (or simple duration if the element does not repeat) and then is frozen or not shown depending on the value of the fill attribute (see the fourth and fifth examples below).

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

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

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

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

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

The min attribute and negative begin times

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

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

Timing attribute value grammars

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

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

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

Begin values

A Begin-value-list is a semi-colon separated list of timing specifiers:

Begin-value-list ::= Begin-value (S? ";" S? Begin-value-list )?
Begin-value      ::= (Offset-value | Syncbase-value 
                      | Event-value | Repeat-value | Accesskey-value
                      | Media-Marker-value | Wallclock-sync-value
                      | "indefinite" )

End values

An End-value-list is a semi-colon separated list of timing specifiers:

End-value-list ::= End-value (S? ";" S? End-value-list )?
End-value      ::= (Offset-value | Syncbase-value 
                      | Event-value | Repeat-value | Accesskey-value
                      | Media-Marker-value | Wallclock-sync-value
                      | "indefinite" )

Parsing timing specifiers

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

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

Clock values

Clock values have the following syntax:

Clock-value         ::= ( Full-clock-value | Partial-clock-value | Timecount-value )
Full-clock-value    ::= Hours ":" Minutes ":" Seconds ("." Fraction)?
Partial-clock-value ::= Minutes ":" Seconds ("." Fraction)?
Timecount-value     ::= Timecount ("." Fraction)? (Metric)?
Metric              ::= "h" | "min" | "s" | "ms"
Hours               ::= DIGIT+ /* any positive number */
Minutes             ::= 2DIGIT /* range from 00 to 59 */
Seconds             ::= 2DIGIT /* range from 00 to 59 */
Fraction            ::= DIGIT+
Timecount           ::= DIGIT+
2DIGIT              ::= DIGIT DIGIT
DIGIT               ::= [0-9]

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

Fractional values are just (base 10) floating point definitions of seconds. The number of digits allowed is unlimited (although actual precision may vary among implementations).

00.5s = 500 milliseconds
00:00.005 = 5 milliseconds

Offset values

An offset value has the following syntax:

Offset-value   ::= ( S? ("+" | "-") S? )? ( Clock-value )

• An offset value allows an optional sign on a clock value, and is used to indicate a positive or negative offset.
• The offset is measured in parent simple time.

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

• For children of a <par> or an <excl>, the offset is relative to the begin of the parent <par> or <excl>.
• For children of a <seq>, the offset is relative to the active end of the previous child. If there is no previous child, the offset is relative to the begin of the parent <seq>. See also The seq time container.

SMIL 1.0 begin and end values

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

ID-Reference values

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

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

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

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

Syncbase values

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

A syncbase value has the following syntax:

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

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

The syncbase element is qualified with one of the following time symbols:

begin

Specifies the begin time of the syncbase element.

end

Specifies the Active End of the syncbase element.

• The time symbol may be followed by an offset value. The offset value specifies an offset from the time (i.e. the begin or active end) specified by the syncbase and time symbol.
• The offset is measured in parent simple time.
• If the clock value is omitted, it defaults to "0".
• No embedded white space is allowed between a syncbase element and a time-symbol.
• White space will be ignored before and after a "+" or "-" for a clock value.
• Leading and trailing white space characters (i.e. before and after the entire syncbase value) will be ignored.

Event values

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

An event value has the following syntax:

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

The symbol Nmtoken is defined in XML 1.1 [XML11].

The eventbase-element must be another element contained in the host document.

If the Eventbase-element term is missing, the event-base element defaults to the element on which the eventbase timing is specified (the current element). A host language designer may override the definition of the default eventbase element. As an example of this, the SMIL 3.0 Animation modules describe Timing integration requirements for the animation elements (animate, animateMotion, etc.). These requirements specify that the default eventbase element is the target element of the animation. See the section Common Animation Integration Requirements.

The event value must specify an Event-symbol. This term is an XML NMTOKEN that specifies the name of the event that is raised on the Event-base element. The host language designer must specify which events may be specified.

• Host language specifications must include a description of legal event names (with "none" as a valid description), and/or allow any name to be used.

• If an integrating language specifies no supported events, the event-base time value is effectively unsupported for that language.

• A host language may choose not to include support for offsets with event values. The language must specify if this support is omitted.

• If the host language allows dynamically created events (as supported by DOM-Level2-Events [DOM2Events]), all possible Event-symbol names cannot be specified and so unrecognized names may not be considered errors.

• Unless explicitly specified by a host language, it is not considered an error to specify an event that cannot be raised on the Event-base element (such as activateEvent or click for audio or other non-visual elements). Since the event will never be raised on the specified element, the event-base value will never be resolved.

The last term specifies an optional Offset-value that is an offset from the time of the event.

• The offset is measured in parent simple time. If this term is omitted, the offset is 0.
• No embedded white space is allowed between an eventbase element and an event-symbol.
• White space will be ignored before and after a "+" or "-" for a clock value.
• Leading and trailing white space characters (i.e. before and after the entire eventbase value) will be ignored.

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

Repeat values

Repeat values are a variant on event values that support a qualified repeat event. The repeat event defined in Events and event model allows an additional suffix to qualify the event based upon an Iteration value.

A repeat value has the following syntax:

Repeat-value       ::= ( Eventbase-element "." )? "repeat(" Iteration ")"
                        ( S? ("+"|"-") S? Clock-value )?
Iteration          ::= DIGIT+

If this qualified form is used, the eventbase value will only be resolved when a repeat is observed that has an Iteration value that matches the specified iteration.

Accesskey values

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

An access key value has the following syntax:

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

The Char symbol is defined in XML 1.1 [XML11].

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

Media marker values

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

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

Wallclock-sync values

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

Wallclock-sync-value  ::= "wallclock(" S? (DateTime | WallTime | Date)  S? ")"
DateTime       ::= Date "T" WallTime
Date           ::= Years "-" Months "-" Days
WallTime       ::= (HHMM-Time | HHMMSS-Time)(TZD)?
HHMM-Time      ::= Hours24 ":" Minutes
HHMMSS-Time    ::= Hours24 ":" Minutes ":" Seconds ("." Fraction)?
Years          ::= 4DIGIT;
Months         ::= 2DIGIT /* range from 01 to 12 */
Days           ::= 2DIGIT /* range from 01 to 31 */
Hours24        ::= 2DIGIT /* range from 00 to 23 */
4DIGIT         ::= DIGIT DIGIT DIGIT DIGIT
TZD            ::= "Z" | (("+" | "-") Hours24 ":" Minutes )

• Exactly the components shown here must be present, with exactly this punctuation.
• Note that the "T" appears literally in the string, to indicate the beginning of the time element, as specified in [ISO8601].

   YYYY-MM-DDThh:mmTZD (e.g. 1997-07-16T19:20+01:00)

   YYYY-MM-DDThh:mm:ssTZD (e.g. 1997-07-16T19:20:30+01:00)

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

There are three ways of handling time zone offsets:

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

• When the document begins, the current wallclock time must be noted - this is the document wallclock begin.
• Wallclock values are then converted to a document time by subtracting the document wallclock begin, and then converting the time to the element's parent time space as for any syncbase value, as though the syncbase were the document body.
• Date wallclock values are treated as a DateTime value of the given date at time 00:00:00.00 in the local time zone.
• WallTime values are treated as a DateTime value on the date of the document wallclock begin at the given time. Specified time zones must be respected, and the time converted into the local time zone before applying the document wallclock begin.

Examples

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

begin="wallclock( 1990-07-28T15:30-08:00 )"

begin="wallclock( 08:00 )"

The endsync attribute

The endsync attribute controls the implicit duration of time containers, as a function of the children. The endsync attribute is only valid for par and excl time container elements, and media elements with timed children (e.g. animate or area elements). Integrating languages may allow the endsync attribute on any element with time container semantics.

• Elements may have an unresolved or indefinite begin time when the parent begins. If an element's unresolved begin time becomes resolved (and definite) before the parent time container ends the simple duration, the element must be considered by the endsync="last" semantics.

  This comment is informative.

  This may chain, so that only one element is running at one point, but before it ends its active duration another interactive element is resolved. It may even yield "dead time" (where nothing is playing), if the resolved begin is after the other elements active end.

• If the endsync semantics consider any child that has an unresolved active duration, then the implicit duration of the time container is also unresolved.

• For the Id-value arg-value variant, the referenced child may have an unresolved begin time. If this causes the active end time to be unresolved as well, the implicit duration of the time container is also unresolved.

• If the endsync semantics consider any child that has a (resolved) indefinite active duration, then the implicit duration of the time container is also indefinite.

• Media element time containers define an intrinsic duration equal to the duration of the referenced media.

  This comment is informative.

  If the referenced media is not continuous, the duration is 0 (endsync="media" will not generally be useful on discrete media).

• If the media argument value is used for an element that does not declare media, the attribute is ignored (as though endsync had not been specified).

• If the Id-value arg-value variant is not an immediate child of the time container, it is as if endsync is not specified.

• For the purpose of parsing the endsync argument value, first, last, all, and media are reserved words and must be escaped with a backslash in order to be used as Id-value's.

Semantics of endsync and dur and end:

• If an element specifies both endsync and dur, the endsync attribute is ignored. The element's simple duration is defined by the value of dur.
• If an element specifies both endsync and end, but none of dur, repeatDur or repeatCount, the endsync attribute is ignored. In this case the element behaves as if only end were specified, therefore the element's implicit duration is indefinite and will be constrained by the end value.

Semantics of endsync and restart:

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

Semantics of endsync and paused elements:

• Note that child elements of an excl that are currently paused (by the excl semantics) have not ended their active duration. Similarly, any element paused via the DOM 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 of endsync.

  This comment is informative.

  For example, if a time container with endsync="last" has paused child elements, the simple duration of the time container will not end until the paused children resume or otherwise end.

The following pseudo-code describes the endsync algorithm:

// 
// boolean timeContainerHasEnded()
//
// method on time containers called to evaluate whether
// time container has ended, according to the rules of endsync.
// Note: Only supported on par and excl
//
// A variant on this could be called when a child end is updated to
// create a scheduled (predicted) end time for the container.
//
// Note that we never check the end time of children - it doesn't matter.
//
// Assumes: 
//     child list is stable during evaluation
//     isActive state of children is up to date for current time.
//      [In practice, this means that the children must all be
//        pre-visited at the current time to see if they are done.
//        If the time container is done, and repeats, the children
//        may be resampled at the modified time.]
//
//   Uses interfaces: 
//   on TimedNode:
//     isActive()             tests if node is currently active
//     hasStarted()           tests if node has (ever) begun
//     begin and end          begin and end TimeValues of node
//
//   on TimeValue         (a list of times for begin or end)
//   is Resolved(t)          true if there is a resolved time
//                                     at or after time t
//

boolean timeContainerHasEnded()
{

TimeInstant now = getCurrentTime(); // normalized for time container

boolean 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 child

if( ( 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 loop

return assumedResult;

} // close timeContainerHasEnded()

The repeatCount, repeatDur, and repeat attributes: repeating elements

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

Examples

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

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

<audio src="background.au" dur="2.5s" repeatCount="2" />

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

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

<img src="foo.jpg" repeatCount="2" />
<img src="bar.png" dur="indefinite" repeatCount="2" />

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

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

<seq begin="5s" repeatCount="3" >
   <img src="img1.jpg" dur="5s" />
   <img src="img2.jpg" dur="4s" />
   <img src="img3.jpg" dur="4s" />
</seq>

The min attribute and restart:

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

SMIL 1.0 repeat (deprecated)

The fill attribute: extending an element

The fill attribute allows an author to specify that an element should be extended beyond the active duration by freezing the final state of the element. The fill attribute is also used to determine the behavior when the active duration is less than the duration specified in the min attribute. For this reason, rather than referring to the end of the active duration, this description refers to the "last instance of the simple duration".

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

The last instance of the simple duration is the last frame or value that was played during the last instance (see The instance times lists) of the simple duration of the element before it finished or was stopped because of an end attribute.

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

• In a par, the element is frozen to extend to the end of the simple duration of the par. In this case, fill="freeze" is equivalent to fill="hold".
• In a seq, the element is frozen to extend to the begin of the next element in the seq or until the end of the simple duration of the seq. This will fill any gap in the presentation (although it may have no effect if the next element begins immediately).
• In an excl, the element is frozen to extend to the begin of the next element to be activated in the excl, or until an element in the excl is resumed, or until the end of the simple duration of the excl. This will fill any gap in the presentation (although it may have no effect if the next element interrupts the current element). Note that if an element is paused, the active duration has not ended, and so the fill attribute does not (yet) apply. See also excl element, in the section ExclSyntax.

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

The fillDefault attribute

The Event sensitivity and fill

The effects of the fill 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 as a and area are still sensitive to user activation (e.g. clicks) when frozen. See also the SMIL 1.0 specification [SMIL10].

<par endsync="last">
   <video src="intro.mpg" begin= "5s" dur="30s" fill="freeze" />
   <audio src="intro.au"  begin= "2s" dur="40s"/>
</par>

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

The restart attribute

• When an element restarts, the primary semantic is that it behaves as though this were the first time the element had begun, independent of any earlier behavior. Any effect of an element playing earlier is no longer applied (including any fill behavior), and only the new current interval of the element is reflected in the presentation. It should be obvious that this definition applies only to the behavior of the element content, and not to the evaluation of the begin and end times lists described in Evaluation of begin and end time lists.
• When an active element restarts, the element first ends the active duration, propagates this to time dependents and raises an endEvent in the normal manner (see also Evaluation of begin and end time lists). Restart semantics are evaluated after the active duration for an element is computed, and so ending the active duration due to a restart is not subject to the semantics of min. See also Computing the active duration.
• The synchronization relationship between an element and its parent time container is re-established when the element restarts. A new synchronization relationship may be defined. See also Controlling runtime synchronization behavior.
• Note that if the parent time container (or any ascendant time container) repeats or restarts, any state associated with restart="never" will be reset, and the element may begin again normally. See also Resetting element state.

The restartDefault attribute may be used to control the default behavior of the restart attribute. This is described below in Controlling the default behavior of restart.

Using restart for toggle activation

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

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

Controlling the default behavior of restart

The following attribute is provided to specify the default behavior for restart:

Resetting element state

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

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

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

Note that when any time container ends its simple duration (including when it repeats), all timed children that are still active are ended. See also Time container constraints on child durations.

When an excl time container restarts or repeats, in addition to ending any active children, the pause queue for the excl is cleared.

The syncBehavior, syncTolerance, and syncMaster attributes: controlling runtime synchronization

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

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

Controlling the default behavior

Two attributes are defined to specify the default behavior for runtime synchronization:

The accumulated synchronization offset

If an element slips synchronization relative to its parent, the amount of this slip at any point is described as the accumulated 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 in Converting between local and global times. The offset is computed as follows:

Let t_c(t_ps) be the computed element active time for an element at the parent simple time t_ps, according to the defined synchronization relationship for the element.

Let t_o(t_ps) be the observed element active time for an element at the parent simple time t_ps.

The accumulated synchronization offset O is:

O = t_o(t_ps) - t_c(t_ps)

This offset is measured in parent simple time.

Attributes for timing integration: timeContainer and timeAction

The timeContainer attribute

XML language elements may be declared to have time container semantics by adding the timeContainer attribute. The syntax is:

Constraints upon the use of the timeContainer attribute are:

• Language designers may restrict the set of elements that may be time containers, but any element may in principle be a time container.
  
• An element with the timeContainer attribute behaves the same as a media time container. If the element has no intrinsic media duration, then the element may behave the same as the respective time container element. Language designers must specify which elements have intrinsic media duration, and how this is defined.
  
• The timeContainer attribute may not be applied to any of the SMIL time container elements par, seq or excl.
  
• The timeContainer attribute may be applied to SMIL media elements (with timed children) to control the behavior of a media time container.

The timeAction attribute

The timeAction 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 which timeAction may be applied. In addition, a host language may specify additional timeAction values. The syntax is:

The intrinsic behavior is defined by a host language. For example in the SMIL language, the intrinsic behavior of media elements is to schedule and control the visibility of the media. For some elements or some languages, the intrinsic behavior may default to one of the other behaviors.

Additional timeAction semantics and constraints:

• SMIL media elements define the intrinsic behavior as the scheduling and playback of the media. When timeAction is set to any other value (besides intrinsic), the intrinsic scheduling behavior will be controlled in addition to the specified timeAction.
  
• SMIL time container elements (par, seq, and excl) define the intrinsic behavior as simply performing the scheduling semantics. When the intrinsic behavior is specified, only the scheduling semantics are controlled. Timing does not otherwise control the presentation styling of the element. When timeAction is set to any other value (besides intrinsic), the intrinsic scheduling behavior will be controlled in addition to the specified timeAction.
  
• It is recommended that phrasal, presentation, and style-like elements (e.g., XHTML's b, em, strong, ...etc.) have an intrinsic behavior that applies the associated semantic (e.g. to embolden or emphasize the content of the element). When timeAction is set to any other value (besides intrinsic), the intrinsic behavior will be controlled in addition to the specified timeAction.
  
• It is recommended that "content" elements (e.g., XHTML's p, div, span) have an intrinsic behavior equivalent to visibility. When timeAction is set to any other value (besides intrinsic), the intrinsic behavior should not be controlled, but rather only the specified timeAction should be applied.
  
• If a language supports CSS styling, the presentation effect of display and visibility should use the CSS override style, rather than setting the original value for the associated properties. This model for presentation values is described in the SMIL 3.0 Animation module.
  
• If a language supports CSS styling, the visibility property should be set to "hidden" when the element is not active or frozen. If the original value of the visibility property was not "hidden", the original value should be used when the element is active or frozen. If the original value of the visibility property was "hidden", the property should be set to "visible" when the element is active or frozen.
  
• If a language does not support CSS styling, the presentation semantics of display and visibility must be specified, or the attribute values must be disallowed.
  
• If a language does not support a "style" attribute, the style value for timeAction should not be allowed.
  
• When the class argument value is specified, the specified class name should be added to the class list of the element when the element is active or frozen. Other values in the class list must be preserved. If the specified class name is specified in the class list (i.e. if it is specified in the class attribute), the class name should be removed from the class list of the element when the element is not active or frozen.
  
• When the none argument value is specified, no action is controlled by the timing, except any intrinsic behavior. This value is generally only useful on an element that also specifies a timeContainer value. In this case, the time containment semantic applies, but no presentation effect is applied to the element.

Certain special elements may have specific intrinsic semantics. For example, linking elements like a and area may have an intrinsic 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 the timeAction attribute on the element. Similarly, link elements could apply a linked stylesheet when the element begins or the language could disallow the timeAction attribute on link.

For details of the CSS properties visibility and display, see [CSS2].

Examples:

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

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

<form ...>
...
   <label for="select_red" smil:begin="focus" smil:dur="5s" smil:timeAction="style"
          style="color:red; font-weight:bold" >
      Make things RED.
   </label>
   <input xml:id="select_red" .../>
   <label for="select_green" smil:begin="focus" smil:dur="5s" smil:timeAction="style"
          style="color:green; font-weight:bold" >
      Make things GREEN.
   </label>
   <input xml:id="select_green" .../>
...
</form>

5.4.4 Elements

The par element

par

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

The implicit syncbase of the child elements of a par is the begin of the par. The default value of begin for children of a par is "0".

The par element supports all element timing.

Implicit duration of par

The implicit duration of a par is controlled by endsync. By default, the implicit duration of a par is defined by the endsync="last" semantics. The implicit duration ends with the last active end of the child elements.

The seq element

seq

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

• The implicit syncbase of the child elements of a seq is the active end of the previous element. Previous means the element that occurs before this element in the sequence time container. For the first child of a sequence (i.e. where no previous sibling exists), the implicit syncbase is the begin of the sequence time container.
• For children of a sequence, the only legal value for begin is a (single) non-negative offset value. 
  The default begin value is "0". None of the following begin values may be used:

  disallowed begin-values:

  ( syncbase-value | event-value | media-marker-value | wallclock-sync-value | repeat-value | accesskey-value | "indefinite" )

• Note however that child elements may define an end that references other syncbases, event-bases, etc.

The seq element itself supports all element timing except endsync.

When a hyperlink traversal targets a child of a seq, and the target child is not currently active, part of the seek action must be to enforce the basic semantic of a seq that only one child may be active at a given time. For details, see Hyperlinks and timing and specifically Implications of beginElement() and hyperlinking for seq and excl time containers.

Implicit duration of seq containers

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

The excl element

excl

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

The implicit syncbase of the child elements of the excl is the begin of the excl. The default value of begin for children of excl is "indefinite". This means that the excl has 0 duration unless a child of the excl has been added to the timegraph.

The excl element itself supports all element timing.

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

Implicit duration of excl containers

• The implicit duration of an excl container is defined the same as for a par container, using the endsync="last" semantics. However, since the default timing for children of excl is interactive, the implicit duration for excl time containers with only default timing on the children will be 0.

The priorityClass element