W3C

Synchronized Multimedia Integration Language (SMIL 3.0)

W3C Proposed Recommendation 06 October 2008

This version:
http://www.w3.org/TR/2008/PR-SMIL3-20081006/
Latest SMIL 3 version:
http://www.w3.org/TR/SMIL3/
Latest SMIL Recommendation:
http://www.w3.org/TR/SMIL/
Previous version:
http://www.w3.org/TR/2008/CR-SMIL3-20080115/
Editors:
Dick Bulterman, CWI - Jack Jansen, CWI - Pablo Cesar, CWI - Sjoerd Mullender, CWI - Eric Hyche, RealNetworks - Marisa DeMeglio, DAISY Consortium - Julien Quint, DAISY Consortium - Hiroshi Kawamura, NRCD - Daniel Weck, NRCD - Xabiel García Pañeda, Universidad de Oviedo - David Melendi, Universidad de Oviedo - Samuel Cruz-Lara, INRIA - Marcin Hanclik ACCESS Co., Ltd - Daniel F. Zucker, Invited Expert - Thierry Michel, W3C.

This document is also available in a non-normative format. single HTML file.


Abstract

This document specifies the third version of the Synchronized Multimedia Integration Language (SMIL, pronounced "smile"). SMIL 3.0 has the following design goals:

Status of this document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is a W3C Proposed Recommendation (PR) of the Synchronized Multimedia Integration Language (SMIL) 3.0.
This document is based upon the SMIL 3.0 Candidate Recommendation published on 15 January 2008. The current document contains editorial improvements, and minor bug fixes. The significant changes in this draft are available in the changeslog.

W3C Advisory Committee Members are invited to send formal review comments to the W3C Team until 06 November 2008. Review comments should be sent to symm-review@w3.org; comments sent there will be made available to members after the review period ends. People wanting their comments visible to members sooner, or to be archived publicly, can send a cc to the ac-forum@w3.org list or to www-archive@w3.org as appropriate. The public is invited to send comments to the public mailing list www-smil@w3.org [archives], including the prefix'[SMIL30 PR]' in the subject line.
After the review the Director will announce the document's disposition. This announcement should be expected no sooner than 14 days after the end of the review.

Feedback received during that review resulted in clarifications but no major changes. The SYMM Working Group believes that this specification addresses all Candidate Recommendation issues. Evidence of interoperability between at least two implementations of this specification are documented in the Implementation Report.

The SMIL 3.0 test suite along with an implementation report are publicly released and are intended solely to be used as proof of SMIL 3.0 implementability. It is only a snapshot of the actual implementation behaviors at one moment of time, as these implementations may not be immediately available to the public. The interoperability data is not intended to be used for assessing or grading the performance of any individual implementation.

This document has been produced by the SYMM Working Group as part of the W3C Synchronized Multimedia Activity, following the procedures set out for the W3C Process. The goals of the SYMM Working Group are discussed in the SYMM Working Group Charter. The authors of this document are the SYMM Working Group members. Different parts of the document have different editors.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Publication as a Proposed Recommendation does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

Quick Table of Contents

Full Table of Contents

1. About SMIL 3.0

Editor
Thierry Michel, W3C.

1.1 Introduction

This section is informative.

This document specifies the third version of the Synchronized Multimedia Integration Language (SMIL, pronounced "smile"). SMIL 3.0 has the following design goals:

SMIL 3.0 is defined as a set of markup modules, which define the semantics and an XML syntax for certain areas of SMIL functionality.

1.2 Content of this Specification

This section is informative.

This specification is structured as a set of Chapters, each defining one or more modules:

This specification also defines five Profiles that are built using the above SMIL 3.0 modules.

1.3 Relation to SMIL 2.1

This section is informative.

SMIL 3.0 is a new version. It is built on top of SMIL 2.1.
A large number of SMIL 2.1 Modules [SMIL21-modules] remain the same in SMIL 3.0.
SMIL 3.0 introduces new SMIL 3.0 Modules with extended functionalities.

SMIL 3.0 also defines three new profiles that are built using the SMIL 3.0 modules specified in this specification.

If this specification is approved as a W3C Recommendation, it will supersede the 13 December 2005 version of the SMIL 2.1 Recommendation [SMIL21].

Note: SMIL document players, those applications that support playback of "application/smil+xml" documents, and host language conformant document profiles must support the deprecated SMIL 2.1 functionalities as well as the new SMIL 3.0 functionalities.

1.4 Summary of Changes for SMIL 3.0

This section is informative.

1.4.1 Functional areas affected by SMIL 3.0

SMIL 3.0 specification provides three classes of changes to the SMIL 2.1 Recommendation, among the functional areas. For more details on the SMIL 3.0 Modules changes, refer to the next SMIL 3.0 Modules chapter.

1- New SMIL 3.0 functional areas

SMIL 3.0 adds the following new sections introducing new modules where new elements or attributes semantics are specified.

2- Revised SMIL 3.0 functional areas

In these sections, updated or new modules are introduced where new and updated elements or attributes semantics are specified.

3- Unchanged SMIL 3.0 functional areas

The modules, elements and attributes semantics in the following sections remain the same as in SMIL2.1 [SMIL21]. There are no major changes to the document; apart from minor issues related to wording, typos, links and references.

1.4.2 Profiles affected by SMIL 3.0

1- New SMIL 3.0 Profiles:

SMIL3.0 adds the following three new Profiles:

2- Updated SMIL 3.0 Profiles:

The following Profiles are updated from SMIL 2.1 [SMIL21] to include new SMIL 3.0 functionalities.

Finally, SMIL 3.0 provides a Scalability Framework, where a family of scalable SMIL profiles may be defined using a sub- or superset of the SMIL 3.0 Language, DAISY, or Unified Mobile Profile profiles, or a superset of the SMIL 3.0 Tiny profile.

1.5 About normative and informative sections

This section is informative.

Throughout the document, normative and informative sections are labelled with following rules:

1.5.1 Section styling

Informative sections are color coded as follows. All other sections (without a gray background and green border) are normative.

This section is informative.

1.6 Conformance

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.

1.7 Acknowledgements

This section is informative.

This document has been prepared by the Synchronized Multimedia Working Group (SYMM WG) of the World Wide Web Consortium.
The SYMM WG which specified SMIL 3.0 included the following individuals:

Dick Bulterman, CWI - Alessio Cartocci, IWA-HWG - Pablo Cesar, CWI - Samuel Cruz-Lara, INRIA - Marisa DeMeglio, DAISY Consortium - Xabiel García Pañeda, Universidad de Oviedo - Luiz Fernando Gomes Soares, Invited Expert - Marcin Hanclik ACCESS Co., Ltd. - Eric Hyche, RealNetworks - Jack Jansen, CWI - Hiroshi Kawamura, NRCD - Nabil Layaïda, INRIA - David Melendi, Universidad de Oviedo, Thierry Michel, W3C - Sjoerd Mullender, CWI - Julien Quint, DAISY Consortium - Petri Vuorimaa, Helsinki University of Technology - Daniel Weck, NRCD - Daniel F. Zucker, Invited Expert.

The former SYMM WG which specified the previous SMIL versions included the following individuals:

Kazuhide Tanaka, ACCESS Co., Ltd. - Hanan Rosenthal, Canon - Jin Yu, Compaq - Pietro Marchisio, CSELT - Lynda Hardman, CWI - Jacco van Ossenbruggen, CWI - Lloyd Rutledge, CWI - Ishan Vaishnavi, CWI - Markku Hakkinen, DAISY Consortium - Olivier Avaro, France Telecom - Vincent Mahe, France Telecom - Ted Wugofski, Gateway (Invited Expert) - Masayuki Hiyama, Glocomm - Keisuke Kamimura, Glocomm - Michelle Y. Kim, IBM - Steve Wood, IBM - Jeff Boston, IBM - Nabil Layaïda, INRIA - Muriel Jourdan, INRIA - Aaron Cohen, Intel - Wayne Carr, Intel - Masaru Sugano, KDDI Corporation - Tomoyuki Shimizu, KDDI Corporation - Marcel Wong, Ericsson - Ken Day, Macromedia - Daniel Weber, Panasonic - Patrick Schmitz, Microsoft - Debbie Newman, Microsoft - Pablo Fernicola, Microsoft - Aaron Patterson, Microsoft - Kevin Gallo, Microsoft - Paul David, Microsoft - Don Cone, Netscape/AOL - Wo Chang, NIST - Guido Grassel, Nokia - Didier Chanut, Nokia - Antti Koivisto, Nokia - Andrei Popescu, Nokia - Roberto Castagno, Nokia - Jack Jansen, Oratrix - Sjoerd Mullender, Oratrix - Dick Bulterman, Oratrix - Kenichi Kubota, Panasonic - Warner ten Kate, Philips - Ramon Clout, Philips - Jeff Ayars, RealNetworks - Erik Hodge, RealNetworks - Rob Lanphier, RealNetworks - Bridie Saccocio, RealNetworks - Eric Hyche, RealNetworks - Robin Haglund, RealNetworks - Yoshihisa Gonno, Sony Corporation - Geoff Freed, WGBH - Philipp Hoschka, W3C - Philippe Le Hégaret, W3C - Thierry Michel, W3C.

1.8 ChangeLog

This section is informative.

The following are the changes done in this document, since the previous SMIL 3.0 CR version.

1. About SMIL 3.0

2. The SMIL 3.0 Modules

3. SMIL 3.0 Structure

4. SMIL 3.0 Media Object

5. SMIL 3.0 Timing and Synchronization

6. SMIL 3.0 Content Control

7. SMIL 3.0 Layout

8. SMIL 3.0 smilText

9. SMIL 3.0 Linking

10. SMIL 3.0 Metainformation

11. SMIL 3.0 Transition Effects

12. SMIL 3.0 Animation

13. SMIL 3.0 State

14. SMIL 3.0 Time Manipulations

15. SMIL 3.0 DOM

16. SMIL 3.0 Scalability Framework

17. SMIL 3.0 Language Profile

18. SMIL 3.0 Unified Mobile Profile

19. SMIL 3.0 DAISY Profile

20. SMIL 3.0 Tiny Profile

21. SMIL 3.0 smilText Profile

Appendix A. SMIL 3.0 DTDs

Appendix B. Index of SMIL 3.0 Modules

Appendix C. Index of SMIL 3.0 Elements

Appendix D. Index of SMIL 3.0 Attributes

Appendix E. SMIL 3.0 References

2. The SMIL 3.0 Modules

Editor:
Thierry MICHEL, W3C.

2.1 Introduction

This section is informative.

Since the publication of SMIL 1.0 [SMIL10], interest in the integration of SMIL concepts with the HTML, the HyperText Markup Language [HTML4], and other XML languages, has grown. Likewise, the W3C HTML Working Group has specified XHTML, the Extensible HyperText Markup Language [XHTML10], in preparation to subset, extend, and integrate it with other languages. The strategy considered for integrating respective functionality with other XML-based languages is based on the concepts of modularization and profiling [SMIL-MOD], [XMOD].

Modularization is an approach in which markup functionality is specified as a set of modules that contain semantically-related XML elements, attributes, and attribute values. Profiling is the creation of an XML-based language through combining these modules, in order to provide the functionality required by a particular application.

Profiling introduces the ability to tailor an XML-based language to specific needs, e.g. to optimize presentation and interaction for the client's capabilities. Profiling also adds the ability for integrating functionality from other markup languages, releasing the language designer from specifying that functionality. Moreover, it provides for consistency in markup through the use of the same model to incorporate a function. Identical constructs ease authoring, while at the user agent side there is a potential for re-use of code. For example, a scheduler supporting SMIL timing and synchronization functionality could be used for SMIL documents, XHTML+SMIL documents, and SVG documents.

Modularization enables language designers to specify dedicated markup intended for integration with other, existing, profiles. Examples of specifications intended for such integration are MathML and XForms [MathML], [XFORMS10].

Modularization and profiling use the extensibility properties of XML, and related technology like XML namespaces and XML Schema [XML11], [XML-NS], [XSCHEMA].

This part of the SMIL 3.0 specification describes the framework on which SMIL modularization and profiling is based, and specifies the SMIL 3.0 Modules, their identifiers, and the requirements for conformance within this framework.

2.2 Modularization and Profiling

This section is informative.

The modularization approach used in this specification derives from that set forth in XHTML Modularization [XMOD]. The framework on which SMIL modularization and profiling is based, is informally described here.

A Module is a collection of semantically-related XML elements, attributes, and attribute values that represents a unit of functionality. Modules are defined in coherent sets.

A Profile is a combination of modules. Modules are atomic, i.e. they may not be subset when included in a profile. Furthermore, a module specification may include a set of integration requirements, to which profiles that include the module must comply.

Commonly, there is a main profile that incorporates nearly all the modules associated with a single namespace. For this version of SMIL, this is the SMIL 3.0 Language profile.

Other profiles may be specified that are subsets of the larger one, or that incorporate a mixture of modules associated with different namespaces. SMIL 3.0 Tiny is an example of the first, XHTML+SMIL of the latter.

Several of SMIL's modules define features that that characterize the core of the functionality provided by SMIL. This is expressed by the notions of host language and integration set. Both of them relate to a set of conformance requirements for language profiles, which includes the requirement to incorporate at least the core set of modules. The set may be different for a host language and an integration set. A host language must incorporate the Structure module; an integration set need not. There may be other differences as well.

The main purpose of profile conformance is to enhance interoperability. Preferably, the mandatory modules for host language conformance are defined in such a way that any document interchanged in a conforming profile will yield a reasonable presentation when the document renderer, while supporting the associated mandatory module set, would ignore all other (unknown) elements and attributes. Here, "reasonable presentation" is to be understood as something intelligible, which is not necessarily a close reflection of the author's original intentions. To achieve the latter, a negotiation would have to be conducted to agree on the specific profile to be used for the document interchange.

2.3 Summary of Changes for the SMIL 3.0 Modules

This section is informative.

SMIL 3.0 specification provides three classes of changes to the SMIL 2.1 Recommendation, among the functional areas;

  1. New Modules are introduced (e.g. the MediaPanZoom module, MediaOpacity, BasicText, TextStyling, TextMotion; StateTest, UserState, StateSubmission, StateInterpolation; StructureLayout modules and DOMTimingMethods.
  2. Former SMIL Modules are revised allowing extended functionalities (example are Metainformation, BasicLayout, MediaParam modules).
  3. Former SMIL Modules are unchanged; the modules, elements and attributes semantics remain the same as in SMIL2.1 [SMIL21]. There are no major changes to the modules; apart from minor issues related to typos, links and references.

The following functional areas are affected by SMIL 3.0:

DOM

Content Control

This functional area is currently unchanged, apart from repartitioning of the content control module structure in order to support the SMIL Tiny profile. In a future version the content control mechanisms specified will be modified to better align with the expression and test logic being developed within the SMIL 3.0 State modules.

Layout

SMIL 3.0 extends the Layout capabilities as follows:

Linking

SMIL 3.0 linking integrates the general features of the XHTML-2 access and role attributes as an extension and replacement for the accessKey attribute. This is expected to result in the deprecation or removal of the accesskey attribute and the accesskey event from the SMIL 2.1 language.

Media Object

SmilText

This new smilText functionality provides a new media type for use in SMIL presentations. The smilText modules provide a text container element with an explicit content model for defining in-line text, and a set of additional elements and attributes to control explicit in-line text rendering.

The following 3 modules are introduced in the new Text functional area allowing use of in-line text content:

In addition, SMIL 3.0 also defines the smilText profile, which allows timed text markup to be placed in a light-weight external container.

Metainformation

Metainformation mechanisms in SMIL 3.0 provide a general purpose approach to attaching metainformation to any element within the presentation.

Structure

The new Identity module identifies the SMIL version and the SMIL profile. This replaces the former SMIL approach of defining separate namespaces for individual modules and profiles.

Timing

The SMIL 3.0 specification leaves the basic syntax and semantics of the SMIL 2.1 timing model [SMIL21-timing] unchanged apart from the following changes:

State

The new modules in this section provide a mechanism whereby the document author may create more complex controlflow than what SMIL provides through the timing and content control modules, without having to go all the way of using a scripting language. One way to provide this is to allow a document to have some explicit state (think: variables) along with ways to modify, use and save this state.

The following 4 modules are introduced in the State functional areas:

2.4 SMIL 3.0 Modules

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.

Table 1: The SMIL 3.0 Modules and their Dependencies.
Module Dependencies
AccessKeyTiming NONE
AlignmentLayout BasicLayout
AudioLayout BasicLayout
BackgroundTilingLayout BasicLayout
BasicAnimation BasicInlineTiming
BasicContentControl NONE
BasicInlineTiming NONE
BasicExclTimeContainers NONE
BasicLayout StructureLayout
BasicLinking NONE
BasicMedia NONE
BasicPriorityClassContainers BasicExclTimeContiners
BasicText NONE
BasicTimeContainers NONE
BasicTransitions NONE
BrushMedia NONE
CustomTestAttributes BasicContentControl
DOMTimingMethods NONE
EventTiming NONE
FillDefault BasicTimeContainers, and/or BasicExclTimeContainers, BasicPriorityClassContainers, and/or TimeContainerAttributes
FullScreenTransitionEffects BasicTransitions
Identity NONE
InlineTransitions NONE
LinkingAttributes NONE
MediaAccessibility MediaDescription
MediaClipMarkers MediaClipping
MediaClipping BasicMedia
MediaDescription NONE
MediaMarkerTiming NONE
MediaOpacity BasicMedia
MediaPanZoom BasicMedia
MediaParam BasicMedia
MediaRenderAtrributes NONE
MetaInformation NONE
MinMaxTiming NONE
MultiArcTiming AccessKeyTiming, and/or BasicInlineTiming, and/or EventTiming, and/or
MediaMarkerTiming, and/or RepeatValueTiming, and/or
SyncbaseTiming, and/or WallclockTiming
MultiWindowLayout BasicLayout
ObjectLinking BasicLinking
OverrideLayout BasicLayout, SubRegionLayout
PrefetchControl NONE
RepeatTiming NONE
RepeatValueTiming NONE
RequiredContentControl NONE
RestartDefault RestartTiming
RestartTiming NONE
SkipContentControl NONE
SplineAnimation BasicAnimation
StateInterpolation NONE
StateSubmission UserState
StateTest NONE
Structure BasicContentControl, and BasicInlineTiming, and BasicLayout, and
BasicLinking, and BasicMedia, and BasicTimeContainers, and
SkipContentControl, and SyncbaseTiming
StructureLayout Structure
SubRegionLayout BasicLayout
SyncbaseTiming NONE
SyncBehavior BasicTimeContainers, and/or
BasicExclTimeContainers, BasicPriorityClassContainers, and/or
TimeContainerAttributes
SyncBehaviorDefault SyncBehavior
SyncMaster SyncBehavior
TextMotion BasicText
TextStyling BasicText
TimeContainerAttributes NONE
TimeManipulations NONE
TransitionModifiers BasicTransitions, and/or InlineTransitions
UserState NONE
WallclockTiming NONE

2.5 Identifiers for SMIL 3.0 MIME Type and the SMIL 3.0 Modules

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.

Table 2: The SMIL 3.0 Module Identifiers.
Module name Identifier
AccessKeyTiming http://www.w3.org/2008/SMIL30/AccessKeyTiming
AudioLayout http://www.w3.org/2008/SMIL30/AudioLayout
BackgroundTilingLayout http://www.w3.org/2008/SMIL30/BackgroundTilingLayout
AlignmentLayout http://www.w3.org/2008/SMIL30/AlignmentLayout
BasicAnimation http://www.w3.org/2008/SMIL30/BasicAnimation
BasicContentControl http://www.w3.org/2008/SMIL30/BasicContentControl
BasicInlineTiming http://www.w3.org/2008/SMIL30/BasicInlineTiming
BasicExclTimeContainers http://www.w3.org/2008/SMIL30/BasicExclTimeContainers
BasicLayout http://www.w3.org/2008/SMIL30/BasicLayout
BasicLinking http://www.w3.org/2008/SMIL30/BasicLinking
BasicMedia http://www.w3.org/2008/SMIL30/BasicMedia
BasicPriorityClassContainers http://www.w3.org/2008/SMIL30/BasicPriorityClassContainers
BasicText http://www.w3.org/2008/SMIL30/BasicText
BasicTimeContainers http://www.w3.org/2008/SMIL30/BasicTimeContainers
BasicTransitions http://www.w3.org/2008/SMIL30/BasicTransitions
BrushMedia http://www.w3.org/2008/SMIL30/BrushMedia
CustomTestAttributes http://www.w3.org/2008/SMIL30/CustomTestAttributes
DOMTimingMethods http://www.w3.org/2008/SMIL30/DOMTimingMethods
EventTiming http://www.w3.org/2008/SMIL30/EventTiming
FillDefault http://www.w3.org/2008/SMIL30/FillDefault
FullScreenTransitionEffects http://www.w3.org/2008/SMIL30/FullScreenTransitionEffects
Identity http://www.w3.org/2008/SMIL30/Identity
InlineTransitions http://www.w3.org/2008/SMIL30/InlineTransitions
LinkingAttributes http://www.w3.org/2008/SMIL30/LinkingAttributes
MediaAccessibility http://www.w3.org/2008/SMIL30/MediaAccessibility
MediaClipMarkers http://www.w3.org/2008/SMIL30/MediaClipMarkers
MediaClipping http://www.w3.org/2008/SMIL30/MediaClipping
MediaDescription http://www.w3.org/2008/SMIL30/MediaDescription
MediaMarkerTiming http://www.w3.org/2008/SMIL30/MediaMarkerTiming
MediaOpacity http://www.w3.org/2008/SMIL30/MediaOpacity
MediaPanZoom http://www.w3.org/2008/SMIL30/MediaPanZoom
MediaParam http://www.w3.org/2008/SMIL30/MediaParam
MediaRenderAttributes http://www.w3.org/2008/SMIL30/MediaRenderAttributes
Metainformation http://www.w3.org/2008/SMIL30/Metainformation
MinMaxTiming http://www.w3.org/2008/SMIL30/MinMaxTiming
MultiArcTiming http://www.w3.org/2008/SMIL30/MultiArcTiming
MultiWindowLayout http://www.w3.org/2008/SMIL30/MultiWindowLayout
ObjectLinking http://www.w3.org/2008/SMIL30/ObjectLinking
OverrideLayout http://www.w3.org/2008/SMIL30/OverrideLayout
PrefetchControl http://www.w3.org/2008/SMIL30/PrefetchControl
RepeatTiming http://www.w3.org/2008/SMIL30/RepeatTiming
RepeatValueTiming http://www.w3.org/2008/SMIL30/RepeatValueTiming
RequiredContentControl http://www.w3.org/2008/SMIL30/RequiredContentControl
RestartDefault http://www.w3.org/2008/SMIL30/RestartDefault
RestartTiming http://www.w3.org/2008/SMIL30/RestartTiming
SkipContentControl http://www.w3.org/2008/SMIL30/SkipContentControl
SplineAnimation http://www.w3.org/2008/SMIL30/SplineAnimation
StateTest http://www.w3.org/2008/SMIL30/StateTest
StateInterpolation http://www.w3.org/2008/SMIL30/StateInterpolation
StateSubmission http://www.w3.org/2008/SMIL30/StateSubmission
Structure http://www.w3.org/2008/SMIL30/Structure
StructureLayout http://www.w3.org/2008/SMIL30/StructureLayout
SubRegionLayout http://www.w3.org/2008/SMIL30/SubRegionLayout
SyncbaseTiming http://www.w3.org/2008/SMIL30/SyncbaseTiming
SyncBehavior http://www.w3.org/2008/SMIL30/SyncBehavior
SyncBehaviorDefault http://www.w3.org/2008/SMIL30/SyncBehaviorDefault
SyncMaster http://www.w3.org/2008/SMIL30/SyncMaster
TextMotion http://www.w3.org/2008/SMIL30/TextMotion
TextStyling http://www.w3.org/2008/SMIL30/TextStyling
TimeContainerAttributes http://www.w3.org/2008/SMIL30/TimeContainerAttributes
TimeManipulations http://www.w3.org/2008/SMIL30/TimeManipulations
TransitionModifiers http://www.w3.org/2008/SMIL30/TransitionModifiers
UserState http://www.w3.org/2008/SMIL30/UserState
WallclockTiming http://www.w3.org/2008/SMIL30/WallclockTiming

2.5.3 Identifiers for SMIL 3.0 Profiles and Features

In addition to the module identifiers above, there are different sets of features that may be expressed using the following identifiers:

http://www.w3.org/2008/SMIL30/NestedTimeContainers
Profile allows nesting of the par and seq time containers.
http://www.w3.org/2008/SMIL30/SMIL20DeprecatedFeatures
Profile supports deprecated SMIL SMIL 2.0 features.
http://www.w3.org/2008/SMIL30/SMIL10DeprecatedFeatures
Profile supports deprecated SMIL 1.0 features.

Modules may also be identified collectively. When grouped into SMIL 3.0 profiles, the module identification string is placed in the profile specification. Profiles will also provide an identification string for their DTD specification. In addition, the following general module collections are defined:

http://www.w3.org/2008/SMIL30/
All the modules specified by the SMIL 3.0 specification.
http://www.w3.org/2008/SMIL30/HostLanguage
The modules required for SMIL Host Language Conformance.
http://www.w3.org/2008/SMIL30/IntegrationSet
The modules required for SMIL Integration Set Conformance.

Implementations must allow these as identifiers for use with the systemRequired attribute from the RequiredContentControl module.

Profiles must identify those attributes for which an implementation must return "true" (this is an integration requirement). Implementations must return "false" for modules or features which are not fully supported.

2.6 SMIL Conformance

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.

2.7 Creating a DTD for a SMIL 3.0 Profile

This section is informative.

This section describes how profiles could be defined using the SMIL 3.0 modular DTDs. The reader is assumed to be familiar with the mechanisms defined in "Modularization of XHTML" [XMOD], in particular Appendix D [XMOD-APPD] and Appendix E [XMOD-APPE]. In general, the SMIL 3.0 modular DTDs use the same mechanisms as the XHTML modular DTDs use. Exceptions to this are:

  1. SMIL supports qualified attribute names for SMIL attributes that may appear on non-SMIL elements. This enables these attributes to use prefixes to indicate that they belong to the SMIL 3.0 namespace.
  2. SMIL supports module level INCLUDE/IGNORE instead of XHTML's element/attlist level. Similar to XHTML Modularization, this prohibits profiles from importing only part of a module -- they have to support either all the elements and attributes or none.

Below, we give a short description of the files that are used to define the SMIL 3.0 modular DTDs. See the table and the end of the section for a complete list of the filenames involved.

Following the same mechanisms as the XHTML modular DTDs, the SMIL 3.0 specification places the XML element declarations (e.g. <!ELEMENT...>) and attribute list declarations (e.g. <!ATTLIST...>) of all SMIL 3.0 elements in separate files, the SMIL module files. A SMIL module file is provided for each functional area in the SMIL 3.0 specification (that is, there is a SMIL module file for animation, layout, timing, etc).

The SMIL module files are used in the normative definitions of the specification of the SMIL 3.0 Language profile. Usage of the same module files for defining other SMIL profiles is recommended, but not required. The requirements that SMIL profiles must follow are stated in the SMIL 3.0 specification, not in the DTD code.

To make the SMIL module files independent of each other, and independent of the profiles, the element and attribute declarations make heavy use of XML entities. This provides profiles with the necessary hooks to define the actual content models and attributes of the SMIL elements.

The SMIL 3.0 Language profile provides examples of how the SMIL module files may be used. Most of the DTD files are reused across the different profiles. Reused are the SMIL module files, the files that define the data types and the common attributes, the "qname" file that takes care of adding namespace prefixes if necessary, and the framework file, which takes care of including files in the appropriate order.

The file that is different for each profile is the driver file, and possibly the document model file. To define a new profile, one has to write the extension module(s), the driver file that defines which modules are used, and a document model file that defines the extended document model. A new profile that merely reuses SMIL 3.0 modules may not need a new document model file. The driver file and document model file are described in more detail below.

The driver file.

This is the file that would be referenced by a document's DOCTYPE declaration. Its main job is to define the modules and features that are included in the DTD. The file contains the following parts.

The document model file.

The document model file contains the XML entities that are used by the SMIL module files to define the content models and attribute lists of the elements in that profile.

Content models generally differ from profile to profile, or contain elements from other modules. To avoid these dependencies in the SMIL module files, content models may be defined in the document model file. The (dummy) default content model as defined in the SMIL module files is "EMPTY" for all SMIL 3.0 elements.

For the same reasons, the SMIL module files only define a default attribute list for their elements. This default list only contains the SMIL 3.0 core attributes and the attributes that are defined in the same SMIL module file. All other attributes may be added to this default list by defining the appropriate XML entities. For example, the Media Objects Module file only adds the core and media related attributes on the media objects; other attributes, such as the timing attributes, are added to this list by the document model file.

Table 7: Formal public identifiers and system identifiers of all files used in the SMIL 3.0 modular DTDs.
Driver files for the predefined profiles
-//W3C//DTD SMIL 3.0 Language//EN http://www.w3.org/2008/SMIL30/SMIL30Language.dtd
-//W3C//DTD SMIL 3.0 Unified Mobile//EN http://www.w3.org/2008/SMIL30/SMIL30UnifiedMobile.dtd
-//W3C//DTD SMIL 3.0 Daisy//EN http://www.w3.org/2008/SMIL30/SMIL30Daisy.dtd
-//W3C//DTD SMIL 3.0 Tiny//EN http://www.w3.org/2008/SMIL30/SMIL30Tiny.dtd
-//W3C//DTD SMIL 3.0 smilText//EN http://www.w3.org/2008/SMIL30/SMIL30smilText.dtd
Document model files for the predefined profiles
-//W3C//ENTITIES SMIL 3.0 Document Model 1.0//EN http://www.w3.org/2008/SMIL30/smil-profile-model-1.mod
SMIL 3.0 module files
-//W3C//ELEMENTS SMIL 3.0 Animation//EN http://www.w3.org/2008/SMIL30/SMIL-anim.mod
-//W3C//ELEMENTS SMIL 3.0 Content Control//EN http://www.w3.org/2008/SMIL30/SMIL-control.mod
-//W3C//ELEMENTS SMIL 3.0 Layout//EN http://www.w3.org/2008/SMIL30/SMIL-layout.mod
-//W3C//ELEMENTS SMIL 3.0 Linking//EN http://www.w3.org/2008/SMIL30/SMIL-link.mod
-//W3C//ELEMENTS SMIL 3.0 Media Objects//EN http://www.w3.org/2008/SMIL30/SMIL-media.mod
-//W3C//ELEMENTS SMIL 3.0 Document Metainformation//EN http://www.w3.org/2008/SMIL30/SMIL-metainformation.mod
-//W3C//ELEMENTS SMIL 3.0 SMILtext//EN http://www.w3.org/2008/SMIL30/SMIL-smiltext.mod
-//W3C//ELEMENTS SMIL 3.0 State//EN http://www.w3.org/2008/SMIL30/SMIL-state.mod
-//W3C//ELEMENTS SMIL 3.0 Document Structure//EN http://www.w3.org/2008/SMIL30/SMIL-struct.mod
-//W3C//ELEMENTS SMIL 3.0 Timesheet//EN http://www.w3.org/2008/SMIL30/SMIL-timesheet.mod
-//W3C//ELEMENTS SMIL 3.0 Timing//EN http://www.w3.org/2008/SMIL30/SMIL-timing.mod
-//W3C//ELEMENTS SMIL 3.0 Transition//EN http://www.w3.org/2008/SMIL30/SMIL-transition.mod
Other utilities: data types, common attributes, qname and frame work files
-//W3C//ENTITIES SMIL 3.0 Common Attributes 1.0//EN http://www.w3.org/2008/SMIL30/smil-attribs-1.mod
-//W3C//ENTITIES SMIL 3.0 Datatypes 1.0//EN http://www.w3.org/2008/SMIL30/smil-datatypes-1.mod
-//W3C//ENTITIES SMIL 3.0 Modular Framework 1.0//EN http://www.w3.org/2008/SMIL30/smil-framework-1.mod
-//W3C//ENTITIES SMIL 3.0 Qualified Names 1.0//EN http://www.w3.org/2008/SMIL30/smil-qname-1.mod

3. SMIL 3.0 Structure

Editor for SMIL 3.0
Thierry Michel, W3C
Editor for Earlier Versions of SMIL
Warner ten Kate, Philips Electronics
Aaron Cohen, Intel.

3.1 Overview and Summary of Changes for SMIL 3.0

This section is informative.

The SMIL 3.0 specification adds the Identity Module to the SMIL 2.1 Structure Module [SMIL21-structure]. It also adds the xml:id attribute, which should be used to assign identity to elements instead of the id attribute, which has been deprecated in SMIL 3.0.

3.2 Introduction

This section is informative

This Section defines the SMIL Structure module and the Identity Module.
The Structure module provides the base elements for structuring SMIL content. These elements act as the root in the content model of all SMIL Host Language conformant language profiles. The Structure module is a mandatory module for SMIL Host Language conformant language profiles. The SMIL Structure module is composed of the smil, head, and body elements, and is compatible with SMIL 1.0 [SMIL10]. The corresponding SMIL 1.0 elements form a subset of the Structure module, both in syntax and semantics, as their attributes and content model is also exposed by the Structure module. Thus, the Structure module is backwards compatible with SMIL 1.0.

The Identity Module provides attributes to identify the SMIL version and the SMIL profile.

3.3 The SMIL 3.0 Structure Module Syntax and Semantics

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 attributes

The smil element may have the following attributes:

xml:id
The xml:id attribute uniquely identifies an element within a document. Its value is an XML identifier. Refer to the "xml:id Version 1.0" Recommendation [XML-ID]. It is strongly recommended that SMIL generators and authors use only xml:id to assign identity to elements.
id (Deprecated.)
The id attribute uniquely identifies an element within a document. Its value is an XML identifier. The id attribute is deprecated in SMIL 3.0; SMIL 3.0 content should use xml:id instead. If the xml:id and id attributes are used on the same element, the id will be ignored. The id attribute may become obsolete in a future version of SMIL. User agents should continue to support this deprecated attribute for reasons of backward compatibility.
class
The class attribute assigns a class name or a set of class names to an element. Any number of elements may be assigned the same class name or names. Multiple class names must be separated by white space characters.
xml:lang
The xml:lang attribute specifies the language of an element, and is specified in XML?1.1 [XML11]. xml:lang differs from systemLanguage test attribute in one important respect. xml:lang provides information about content's language independent of what implementations do with the information, whereas systemLanguage is a test attribute with specific associated behavior (see systemLanguage in SMIL 3.0 BasicContentControl Module for details).
title
The title attribute offers advisory information about the element for which it is set. Values of the title attribute may be rendered by user agents in a variety of ways. For instance, visual browsers frequently display the title as a "tool tip" (a short message that appears when the pointing device pauses over an object).
xmlns
The xmlns attribute declares an XML namespace, and is defined in "Namespaces in XML" [XML-NS].
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 attributes

The head element may have the following attributes:

xml:id
Defined in xml:id under the smil element.
id
Defined in id under the smil element. It is recommended to use xml:id instead.
class
Defined in class under the smil element.
xml:lang
Defined in xml:lang under the smil element.
title
Defined in title under the smil element.
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.

Element attributes

The body element may have the following attributes:

xml:id
Defined in xml:id under the smil element.
id (Deprecated.)
Defined in id under the smil element. It is recommended to use xml:id instead.
class
Defined in class under the smil element.
xml:lang
Defined in xml:lang under the smil element.
title
Defined in title under the smil element.

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.

3.4 Integrating the SMIL Structure 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].

3.5 The SMIL 3.0 Identity Module

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.

Attribute definition

This section defines the attributes that make up the SMIL 3.0 Identity Module.

version
value: version-number
version-number ::= "3.0"
The version attribute identifies the SMIL version number. If the version attribute value is different from the above value, the user agent should specify an error. See also Handling syntax errors.
baseProfile
value: profile-name
profile-name ::= "Language" | "UnifiedMobile" | "Daisy" | "Tiny" | "smilText" | user-defined-profile-name
user-defined-profile-name ::= "x-" NMTOKEN
The baseProfile attribute specifes the SMIL Profile used. If the baseProfile attribute value is different from the above values, the user agent should specify an error. See also Handling syntax errors.

This section is informative

Example of version and baseProfile attribute use

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

4. SMIL 3.0 Media Object

Editor for SMIL 3.0
Dick Bulterman, CWI
Eric Hyche, RealNetworks.
Editor for SMIL 2.0
Dick Bulterman, CWI
Rob Lanphier, RealNetworks.

4.1 Changes for SMIL 3.0

This section is informative.

There are three major changes to the Media Object modules for SMIL 3.0: the first is the splitting of the SMIL 2.1 MediaParam module into two modules: the MediaParam and MediaRenderAttributes modules; the second is the introduction of the MediaOpacity module, containing new rendering attributes for chroma key and opacity control; the third is the introduction of the MediaPanZoom module. The rationale for these changes is:

  1. The splitting of the SMIL 2.1 MediaParam module provides a better differentiation of functionality, which may help user agent profile designers be more selective in the features they wish to support.
  2. The MediaOpacity module is added to define control over various aspects of media opacity using the mediaOpacity, mediaBackgroundOpacity, chromaKey, chromaKeyOpacity, and chromaKeyTolerance attributes.
  3. The MediaPanZoom module defines the panZoom attribute to provide a framework for panning and zooming over media content. (This attribute is based largely on equivalent functionality in the SVG viewBox attribute.)

The MediaParam module also includes new text that explicitly discusses the behavior of adding the various media control attributes defined in that section to a SMIL layout region definition as a means of providing a global mechanism for applying default attribute settings to all content rendered within that region.

A number of editorial changes have also been integrated into the various Media Object modules descriptions; these do not impact the functionality defined in earlier versions of SMIL.

4.2 Introduction

This section is informative.

This section defines the SMIL media object modules, which are composed of the BasicMedia module and nine modules with additional functionality that build on top of the BasicMedia module: the BrushMedia, MediaClipping, MediaClipMarkers, MediaParam, MediaRenderAttributes, MediaOpacity, MediaAccessibility, MediaDescription, and MediaPanZoom modules. These modules contain elements and attributes used to reference external media objects or control media object rendering behavior. Since these elements and attributes are defined in a series of modules, designers of other markup languages may reuse the SMIL media module when they wish to include media objects into their language.

The differences between current media object functionality and that provided by the SMIL 1.0 specification are explained in Appendix A.

4.3 Definitions

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.

4.4 SMIL BasicMedia Module

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.

This section is informative.

Authors are encouraged to use meaningful synonyms (animation, audio, img, video, text or textstream) when referencing external media objects. This is in order to increase the readability of the SMIL document. Some SMIL implementations may require the use of an element type that matches the information type of the object. When in doubt about the group of a media object, authors should use the generic "ref" element.

The animation element defined here should not be confused with the elements defined in the SMIL 3.0 Animation Module. The animation element defined in this module is used to include an external animation object file (such as a vector graphics animation) by reference. This is in contrast to the elements defined in the Animation module, which provide an in-line syntax for the animation of attributes and properties of other elements.

SMIL 3.0 also supports the smilText element for defining in-line timed text content. This functionality is described in the smilText Modules specification.

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

Attributes Definitions

Languages implementing the SMIL BasicMedia Module must define which attributes may be attached to media object elements. In all languages implementing the SMIL BasicMedia module, media object elements may have the following attributes:

src
The value of the src attribute is the IRI [IRI] of the media element, used for locating and fetching the associated media.

The attribute supports fragment identifiers and the '#' connector in the IRI value. The fragment part is an id value that identifies one of the elements within the referenced media item. With this construct, SMIL 3.0 supports locators as currently used in HTML (that is, it uses locators of the form http://www.example.org/some/path#anchor1), with the difference that the values are of unique identifiers and not the values of "name" attributes. Generally speaking, this type of addressing implies that the target media is of a structured type that supports the concept of id, such as HTML or XML-based languages.

Note that this attribute is not required. A media object with no src attribute has an intrinsic duration of zero, and participates in timing just as any other media element. No media will be fetched by the SMIL implementation for a media element without a src attribute.

type
Content type of the media object referenced by the src attribute. The usage of this attribute depends on the protocol of the src attribute.
RTSP [RTSP]
The type attribute is used for purposes of content selection and when the type of the referenced media is not otherwise available. It may be overridden by the contents of the RTSP DESCRIBE response or by the static RTP payload number.
HTTP [HTTP]
The type attribute is used as an alternative method of content selection and when the type of the referenced media is not otherwise available. It may override the contents of the "Content-type" field in an HTTP exchange only if a user has allowed such overrides, as specified in the TAG Finding Authoritative Metadata [AM]. The nominal precedence order for type resolution is: via the HTTP content-type field, via the type attribute, and then by using other clues (such as file inspection or use of the file extension).
FTP [FTP] and local file playback IRI [URI]
The type attribute value takes precedence over other possible sources of the media type (for instance, the file extension).

When the content represented by a URL is available in many data formats, implementations MAY use the type value to influence which of the multiple formats is used. For instance, on a server implementing HTTP content negotiation, the client may use the type attribute to order the preferences in the negotiation. The type attribute is not intended for use in media sub-stream selection.

For protocols not enumerated in this specification, implementations should use the following rules: When the media is encapsulated in a media file and delivered intact to the SMIL user agent via a protocol designed for delivery as a complete file, the media type as provided by this protocol should take precedence over the type attribute value. For protocols which deliver the media in a media-aware fashion, such as those delivering media in a manner using or dependent upon the specific type of media, the application of the type attribute is not defined by this specification.

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.

4.5 SMIL MediaParam Module

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.

Attribute definitions
name
(CDATA) This attribute defines the name of a run-time parameter, assumed to be known by the inserted object. Whether the property name is case-sensitive depends on the specific object implementation.
value
(CDATA) This attribute specifies the value of a run-time parameter specified by name. Property values have no meaning to SMIL; their meaning is determined by the object in question.
valuetype
["data"|"ref"|"object"] This attribute specifies the type of the value attribute. Possible values:
  • data: This is default value for the attribute. It means that the value specified by value will be evaluated and passed to the object's implementation as a string.
  • ref: The value specified by value is a IRI [IRI] that designates a resource where run-time values are stored. This allows support tools to identify URIs given as parameters. The IRI must be passed to the object as is, i.e., unresolved.
  • object: The value specified by value is an identifier that refers to a media object declaration in the same document. The identifier must be the value of the id attribute set for the declared media object element.
type
This attribute specifies the content type of the resource designated by the value attribute only in the case where valuetype is set to "ref". This attribute thus specifies for the user agent, the type of values that will be found at the IRI designated by value. See 6.7 Content Type in [HTML4] for more information.

Example

This section is informative.

To illustrate the use of param, suppose that we have a facial animation plug-in that is able to accept different moods and accessories associated with characters. These could be defined in the following way:
<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.

Element attributes

This element does not define any new attributes. Profiles integrating this element must specify an attribute of type ID [XML11] by which the param group is referenced in a media object reference. For SMIL 3.0, the xml:id attribute will typically be used.

Examples

This section is informative.

This section contains several fragments that illustrate uses of the paramGroup element.

In the following fragment, a paramGroup is created to define parameters that are passed to several different media objects:

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

In the following example, a media object provides an additional param value:

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

In this final example, a media object provides a duplicate param value. The behavior in this case depends on the media renderer; all param values are passed to the renderer in the lexical order of the SMIL source file. It is expected that the lexically last value for any parameter sent to the renderer be used, if possible.

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

paramGroup
Used to specify the name of a paramGroup that was defined in the document head. The value is a single IDREF [XML11] that refers to the ID [XML11] of a paramGroup element. If the named paramGroup does not exist, this attribute is ignored. If this attribute is defined on a SMIL layout region definition, it specifies a default value for all content displayed within that region.

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.

4.6 SMIL MediaRenderAttributes Module

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.

erase
Controls the behavior of the media object after the effects of any timing are complete. For example, when SMIL Timing is applied to a media element, erase controls the display of the media when the active duration of the element and when the freeze period defined by the fill attribute is complete (see SMIL Timing and Synchronization module). If this attribute is defined on a SMIL layout region definition, it specifies a default value for all content displayed within that region.

Values:

whenDone (default)
When this is specified (or implied) the media removal occurs at the end of any applied timing.
never
When this value is specified, the last state of the media is kept displayed until the display area is reused (or if the display area is already being used by another media object). Any profile that integrates this element must define what is meant by "display area" and further define the interaction. Intrinsic hyperlinks (e.g., Flash, HTML) and explicit hyperlinks (e.g., area, a) stay active as long as the hyperlink is displayed. If timing is re-applied to an element, the effect of the erase=never is cleared. For example, when an element is restarted according to the SMIL Timing and Synchronization module, the element is cleared immediately before it restarts.

Example:

This section is informative.

<par>
  <seq>
    <par>
      <img src="image1.jpg" region="foo1" fill="freeze" erase="never" .../>
      <audio src="audio1.au"/>        
    </par>

    <par>
      <img src="image2.jpg" region="foo2" fill="freeze" erase="never" .../>
      <audio src="audio2.au"/>        
    </par>
     ...
    <par>
      <img src="imageN.jpg" region="fooN" fill="freeze" erase="never" .../>
      <audio src="audioN.au"/>        
    </par>
  </seq>
</par>

In this example, each image is successively displayed and remains displayed until the end of the presentation.

mediaRepeat
Used to strip the intrinsic repeat value of the underlying media object. The interpretation of this attribute is specific to the media type of the media object, and is only applicable to those media types for which there is a definition of a repeat value found in the media type format specification. Media type viewers used in SMIL implementations should expose an interface for controlling the repeat value of the media for this attribute to be applied. For all media types where there is an expectation of interoperability between SMIL implementations, there should be a formal specification of the exact repeat value to which the mediaRepeat attribute applies. If this attribute is defined on a SMIL layout region definition, it specifies a default value for all content displayed within that region.

Values:

strip
Strip the intrinsic repeat value of the media object.
preserve (default)
Leave the intrinsic repeat value of the media object intact.

As an example of how this would be used, many animated GIFs intrinsically repeat indefinitely. The application of mediaRepeat= "strip" allows an author to remove the intrinsic repeat behavior of an animated GIF on a per-reference basis, causing the animation to display only once, regardless of the repeat value embedded in the GIF.

When mediaRepeat is used in conjunction with SMIL Timing Module attributes, this attribute is applied first, so that the repeat behavior can then be controlled with the SMIL Timing Module attributes such as repeatCount and repeatDur.

sensitivity
Used to provide author control over the sensitivity of media to user interface selection events, such as the SMIL 2.1 activateEvent, and hyperlink activation. If the media is sensitive at the event location, it captures the event, and will not pass the event through to underlying media objects. If not, it allows the event to be passed through to any media objects lower in the display hierarchy. If this attribute is defined on a SMIL layout region definition, it specifies a default value for all content displayed within that region.

Values:

opaque
The media is sensitive to user interface selection events over the entire area of the media. This is the default.
transparent
The media is not sensitive to user interface selection events over the entire area of the media. Any user interface selection events will be "passed through" to any underlying media.
percentage-value
The media sensitivity to user interface selection events is dependent upon the opacity of the media at the location of the event (the alpha channel value). If rendered media supports an alpha channel and the opacity of the media is less than the given percentage value at the event location, the behavior will be transparent as specified above. Otherwise the behavior will be as opaque. Valid values are non-negative CSS2 percentage values.

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.

4.7 SMIL MediaOpacity Module

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.

chromaKey
This attribute defines the color to be used for chroma key opacity manipulation. It accepts a single CSS2 color value. If media objects or implementations cannot support manipulation of the chroma key value, this attribute is ignored. If this attribute is defined on a SMIL layout region definition, it specifies a default value for all content displayed within that region.
chromaKeyOpacity
This attribute defines the opacity of the chroma key value defined with the chromaKey attribute. It accepts a percentage value in the range 0-100% or a number in the range 0.0-1.0, with 100% or 1.0 meaning fully opaque. If a chroma key color is defined, the default value is 0% (fully transparent). If no chroma key color is defined or if implementations cannot support manipulation of the media opacity value, this attribute is ignored. If this attribute is defined on a SMIL layout region definition, it specifies a default value for all content displayed within that region.
chromaKeyTolerance
This attribute defines a color value that specifies a tolerance value that is added and subtracted from the effective chroma key. If a chroma key color was defined, the default value of this attribute is #000000. If no chroma key color was defined or if implementations cannot support manipulation of the chroma key value, this attribute is ignored. If this attribute is defined on a SMIL layout region definition, it specifies a default value for all content displayed within that region.
mediaOpacity
This attribute defines the opacity of the media object. It accepts a percentage value in the range 0-100% or a number in the range 0.0-1.0, with 100% or 1.0 meaning fully opaque. If implementations cannot support manipulation of the media opacity value, this attribute is ignored. The default value of this attribute is 100%. If this attribute is defined on a SMIL layout region definition, it specifies a default value for all content displayed within that region. The media opacity manipulation does not apply to a background color for a media object, if such a color is defined. The background color opacity is manipulated using the mediaBackgroundOpacity attribute.
mediaBackgroundOpacity
This attribute defines the background color opacity of the media object for media objects that explicitly define a media background color. It accepts a percentage value in the range 0-100% or a number in the range 0.0-1.0, with 100% or 1.0 meaning fully opaque. If either media objects or implementations cannot support manipulation of the media background color opacity, this attribute is ignored. The default value of this attribute is 100%. If this attribute is defined on a SMIL layout region definition, it specifies a default value for all media background opacity displayed within that region.

This section is informative.

The attributes in this module allow the opacity (that is, the degree to which a media object is transparent) to be defined. Opacity may be controlled in several ways, depending on the type of media being used. For unstructured media (that is, media that does not contain an explicitly-defined background color), the chromaKey attribute may be used to identify a particular color that will serve as the background color for purposes of opacity manipulation. If a chromaKey is used, the chromaKeyOpacity attribute may specify the degree of transparency desired. Since the color used to define a background may not be exactly preserved within a media object, the chromaKeyTolerance attribute allows a tolerance range to be defined for the chroma key color.

Some media objects, such as RealText, smilText, GIF, PNG, and Flash, define an explicit background color. In these cases, the specification of the opacity of that color can be done using the mediaBackgroundOpacity attribute. In these cases, only the defined color is manipulated.

In addition to specifying the transparency level of a particular background color, SMIL also allows the specification of the transparency level of a total media object. This is accomplished using the mediaOpacity attribute.

Note that SMIL layout also defines the backgroundOpacity attribute to control the transparency of a layout region.

4.7.3 Integration Requirements

This module does not introduce any special integration constraints.

4.8 SMIL MediaClipping Module

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

clipBegin (clip-begin)
The clipBegin attribute specifies the beginning of a sub-clip of a continuous media object as offset from the start of the media object. This offset is measured in normal media playback time from the beginning of the media.
Values in the clipBegin attribute have the following syntax:
Clip-value-MediaClipping ::= [ Metric "=" ] ( Clock-val | Smpte-val )
Metric            ::= Smpte-type | "npt" 
Smpte-type        ::= "smpte" | "smpte-30-drop" | "smpte-25"
Smpte-val         ::= Hours ":" Minutes ":" Seconds 
                      [ ":" Frames [ "." Subframes ]]
Hours             ::= DIGIT+
Minutes           ::= DIGIT DIGIT /* range from 00 to 59 */
Seconds           ::= DIGIT DIGIT /* range from 00 to 59 */

Frames            ::= DIGIT DIGIT /* smpte range = 00-29, smpte-30-drop range = 00-29, smpte-25 range = 00-24 */
Subframes         ::= DIGIT DIGIT /* smpte range = 00-01, smpte-30-drop range = 00-01, smpte-25 range = 00-01 */
DIGIT             ::= [0-9]
      

The value of this attribute consists of a metric specifier, followed by a time value whose syntax and semantics depend on the metric specifier. The following formats are allowed:

SMPTE Timestamp
SMPTE time codes [SMPTE] may be used for frame-level access accuracy. The metric specifier may have the following values:
smpte
smpte-30-drop
These values indicate the use of the "SMPTE 30 drop" format (approximately 29.97 frames per second), as defined in the SMPTE specification (also referred to as "NTSC drop frame"). The "frames" field in the time value may assume the values 0 through 29. The difference between 30 and 29.97 frames per second is handled by dropping the first two frame indices (values 00 and 01) of every minute, except every tenth minute.
smpte-25
The "frames" field in the time specification may assume the values 0 through 24. This corresponds to the PAL standard as noted in [SMPTE]

The time value has the format hours:minutes:seconds:frames.subframes. If the subframe value is zero, it may be omitted. Subframes are measured in one-hundredths of a frame.
Examples:
clipBegin="smpte=10:12:33"

This section is informative.

The introduction of subframe notation in SMIL 2.1 introduced an inconsistency with SMIL 1.0. As of this draft, SMIL 3.0 has deprecated the subframe notation.

Normal Play Time
Normal Play Time expresses time in terms of SMIL clock values. The metric specifier is "npt", and the syntax of the time value is identical to the syntax of SMIL clock values.
Examples:
clipBegin="npt=123.45s"
clipBegin="npt=12:05:35.3
"
Marker
Not defined in this module. See clipBegin Media Marker attribute extension in the MediaClipMarkers module.

If no metric specifier is given, then a default of "npt=" is presumed.

When used in conjunction with the timing attributes from the SMIL Timing Module, this attribute is applied before any SMIL Timing Module attributes.

clipBegin may also be expressed as clip-begin for compatibility with SMIL 1.0. Software supporting the SMIL 2.1 Language Profile must be able to handle both clipBegin and clip-begin, whereas software supporting only the SMIL MediaClipping module only needs to support clipBegin. If an element contains both a clipBegin and a clip-begin attribute, then clipBegin takes precedence over clip-begin.

Example:

This section is informative.

<audio src="radio.wav" clip-begin="5s" clipBegin="10s" />

The clip begins at second 10 of the audio, and not at second 5, since the clip-begin attribute is ignored. A strict SMIL 1.0 implementation will start the clip at second 5 of the audio, since the clipBegin attribute will not be recognized by that implementation. See Changes to SMIL 1.0 Media Object Attributes for more discussion on this topic.

clipEnd (clip-end)
The clipEnd attribute specifies the end of a sub-clip of a continuous media object as offset from the start of the media object. This offset is measured in normal media playback time from the beginning of the media. It uses the same attribute value syntax as the clipBegin attribute.
If the value of the clipEnd attribute exceeds the duration of the media object, the value is ignored, and the clip end is set equal to the effective end of the media object. clipEnd may also be expressed as clip-end for compatibility with SMIL 1.0. Software supporting the SMIL 2.1 Language Profile must be able to handle both clipEnd and clip-end, whereas software supporting only the SMIL media object module only needs to support clipEnd. If an element contains both a clipEnd and a clip-end attribute, then clipEnd takes precedence over clip-end. When used in conjunction with the timing attributes from the SMIL Timing Module, this attribute is applied before any SMIL Timing Module attributes.

See Changes to SMIL 1.0 Media Object Attributes for more discussion on this topic.

4.9 SMIL MediaClipMarkers Module

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

clipBegin Media Marker attribute extension
Used to define a clip using named time points in a media object, rather than using clock values or SMPTE values. The metric specifier is "marker", and the marker value is a IRI (see [IRI] ). The IRI is relative to the src attribute, rather than to the document root or the XML base of the SMIL document.

Clip-value-MediaClipMarkers ::= Clip-value-MediaClipping |
                      "marker" "=" URI-reference
   /* "URI-reference" is defined in  [URI]  */

Example: Assume that a recorded radio transmission consists of a sequence of songs, which are separated by announcements by a disk jockey. The audio format supports marked time points, and the begin of each song or announcement with number X is marked as songX or djX respectively. To extract the first song using the "marker" metric, the following audio media element may be used:

<audio clipBegin="marker=#song1" clipEnd="marker=#dj1" />
clipEnd Media Marker attribute extension
clipEnd media markers use the same attribute value syntax as the clipBegin media marker extension media marker attribute extension. For the complete description, see clipBegin media marker extension.

4.10 SMIL BrushMedia Module

This section is normative.

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

Attribute definitions
color
The use and definition of this attribute are identical to the "background-color" property in the CSS2 specification.

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.

4.11 SMIL MediaAccessibility Module

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

Attribute definitions
alt
For user agents that cannot display a particular media object, this attribute specifies alternate text. alt may be displayed in addition to the media, or instead of media when the user has configured the user agent to not display the given media type.

It is strongly recommended that all media object elements have an "alt" attribute with a brief, meaningful description. Authoring tools should ensure that no element may be introduced into a SMIL document without this attribute.

The value of this attribute is a CDATA text string.

longdesc
This attribute specifies a IRI link ([IRI] ) to a long description of a media object. This description should supplement the short description provided using the alt attribute or the abstract attribute. When the media object has associated hyperlinked content, this attribute should provide information about the hyperlinked content.

readIndex
This attribute specifies the position of the current element in the order in which longdesc, title and alt text are read aloud by assistive devices (such as screen readers) for the current document. User agents should ignore leading zeros. The default value is 0.

Elements that contain alt, title or longdesc attributes are read by the assistive technology according to the following rules:

  • Those elements that assign a positive value to the readindex attribute are read out first. Navigation proceeds from the element with the lowest readindex value to the element with the highest value. Values need not be sequential nor must they begin with any particular value. Elements that have identical readindex values should be read out in the order they appear in the character stream of the document.
  • Those elements that assign it a value of "0" are read out in the order they appear in the character stream of the document.
  • Elements in a switch statement that have test-attributes which evaluate to "false" are not read out.

Example

This section is informative.

<par>
  <video xml:id="carvideo" src="car.rm" region="videoregion" title="Car video"
         alt="Illustration of relativistic time dilation and length 
              contraction." 
         longdesc="carvideodesc.html" readIndex="3"/>
  <audio xml:id="caraudio" src="caraudio.rm" region="videoregion" 
         title="Car presentation voiceover" begin="bar.begin"/>
  <animation xml:id="cardiagram" src="car.svg" region="animregion" 
         title="Diagram of the car" readIndex="2"/>
  <img xml:id="scvad" src="scv.png" region="videoregion" 
         title="Advertisement for Sugar Coated Vegetables"
         readIndex="1"/>
</par>

In this example, an assistive device that is presenting titles should present the "scvad" element title first (having the lowest readIndex value of "1"), followed by the "cardiagram" title, followed by the "carvideo" element title, and finally present the "caraudio" element title (having an implicit readIndex value of "0").

Note that not all examples in this specification use all media accessibility attributes because the purpose of the sample code is to illustrate specific language features.

4.12 SMIL MediaDescription Module

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

Attribute definitions
abstract
A brief description of the content contained in the element. Unlike alt, this attribute is generally not displayed as alternate content to the media object. It is typically used as a description when table of contents information is generated from a SMIL presentation, and typically contains more information than would be advisable to put in an alt attribute.

This attribute is deprecated in favor of using appropriate SMIL metadata markup in RDF. For example, this attribute maps well to the "description" attribute as defined by the Dublin Core Metadata Initiative [DC] .

author
The name of the author of the content contained in the element.

The value of this attribute is a CDATA text string.

copyright
The copyright notice of the content contained in the element.

The value of this attribute is a CDATA text string.

title
The title attribute as defined in the SMIL Structure module. It is strongly recommended that all media object elements have a title attribute with a brief, meaningful description. Authoring tools should ensure that no element may be introduced into a SMIL document without this attribute.
xml:lang
Used to identify the natural or formal language for the element. For a complete description, see section 2.12 Language Identification of [XML11].

xml:lang differs from the systemLanguage test attribute in one important respect. xml:lang provides information about the content's language independent of what implementations do with the information, whereas systemLanguage is a test attribute with specific associated behavior (see systemLanguage in SMIL Content Control Module for details)

This section is informative.

SMIL 3.0 also supports the use of the element within the MetaInformation Module to supply additional or alternative forms of metainformation for any media object.

4.13 MediaPanZoom Module

This section is normative.

4.13.1 Overview

This section is informative.

The SMIL MediaPanZoom module integrates the functionality of the SVG viewBox attribute and adapts it for use within the SMIL media framework. The SMIL panZoom attribute allows a SMIL author to define a two-dimensional extent over the visible surface of a media object and to subsequently project the contents within the panZoom area into a SMIL presentation.

Most of SMIL's layout elements and attributes provide the ability to define and manage a two-dimensional rendering space. This space is defined relative to a root-layout (or topLayout) specification. All of the coordinate and size specifications are in terms of the coordinate space defined for the layout root. In contrast, the panZoom attribute allows users to define an area in terms of the coordinate space used by the media object that is associated with the panZoom area. The panZoom area may be smaller, equal to, or larger than the related media object.

The following illustration shows three views of a 300x200 pixel image. In the left view, a panZoom area is shown that is the same size as the media object; in the middle view, a panZoom area is defined that covers the middle part of the image only; in the right view, a panZoom area is illustrated that is positioned (in both dimensions) partially outside the media object. Note that while this illustration shows the panZoom area projected onto an image, similar illustrations could be defined for videos or text objects, or any other object that may be mapped to a particular media bounding box.

Picture showing a base image and three panZoom area examples

Once a portion of a media object's visible area is defined with a panZoom area, the portion within the panZoom area is processed further as if it defined the full native view of the media object. The content within the panZoom area is projected into a region in a manner that is dependent on the region element associated with that object, including any scaling dictated by the fit attribute or (if appropriate), sub-region positioning and alignment directives.

If the region and the panZoom area have the same aspect ratios, then the panZoom area will, by default, fill the entire region. If the effective pixel dimensions of the region are larger than that of the panZoom area, the effect will be an enlargement of the media content. If the effective pixel dimensions of the window are smaller than that of the panZoom area, the effect will be a reduction in size of the media object. Other effects may be obtained by manipulating the fit attribute of the region.

If supported by the profile implementing this module, a dynamic pan-and-zoom effect may be obtained by applying standard SMIL animation primitives to the dimensions of the panZoom area. A pan effect may be obtained by varying the X and Y positioning values, and a zoom effect may be obtained by changing the size dimensions of the panZoom area. Examples of these effects are given later in this module description. Given the nature of independently animating collections of attribute values, care should be taken when specifying animation behavior.

If a panZoom area extends past the viewable extents of a media object (such as in the rightmost illustration, above), then the effective contents of these extended areas will be transparent.

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 attributes
panZoom
This attribute specifies a rectangular area in media coordinates that defines the portion of a media object that is to be used within a SMIL presentation. The panZoom attribute defines an ordered list of four values, separated by a comma:
left
A value (using CSS2 pixel or percentage values) that defines the minimum X coordinate of a rectangle in media space that serves as the X origin of the panZoom area. If pixel notation is used, the 'px' suffix may be omitted. An effective value of '0px' represents the left edge of the media object.
top
A value (using CSS2 pixel or percentage values) that defines the minimum Y coordinate of a rectangle in media space that serves as the Y origin of the panZoom area. If pixel notation is used, the 'px' suffix may be omitted. A value of '0' represents the top edge of the media object.
width
A non-negative length value (using CSS2 pixel or non-negative percentage values) that defines the horizontal dimension of the panZoom area. If pixel notation is used, the 'px' suffix may be omitted. A negative value is an error. The default value of width is set to the intrinsic width of the associated media object.
height
A non-negative length value (using CSS2 pixel or non-negative percentage values) that defines the vertical dimension of the panZoom area. If pixel notation is used, the 'px' suffix may be omitted. A negative value is an error. The default value of set to the intrinsic height of the associated media object.
The default panZoom area behavior is to select the entire visual space of the media object; this is equivalent to panZoom="0, 0, 100%, 100%".

The panZoom area is processed on the media object before any other SMIL layout processing occurs. The actual visual rendering of the content resulting from the processed panZoom area will be determined by, among other factors: the size of the target region, the application of sub-region positioning in that region (if supported by the profile), the value of the fit attribute on the region, and the effect of SMIL alignment attributes (if supported by the profile).

This section is informative.

If the profile integrating the panZoom element allows each of the attribute values to be animated, care should be taken to choose an animation calculation mode that will yield predictable results (such as using a linear mode). The animation of mixed percentage/pixel values for height and width is not recommended.

Note that the specification of negative values for left and top is not an error; this allows placing (a portion of) the panZoom area outside of the media.

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 attributes
panZoom
This attribute is identical in definition to the panZoom attribute defined for the ref element in this section, with the exception that it defines a default panZoom area that is applied to all media rendered in the associated region. All other aspects of panZoom area processing are the same as with the ref element, except that the values defined for the panZoom area on a region may be overridden by a panZoom area specification on the ref element.
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:
    A panZoom area projection that is the same size as the target region.
    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:
    A panZoom area projection that is smaller than the target region, resulting in a zoom effect.

    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:
    A panZoom area projection that is smaller than the target region, but with a fit=
  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:
    A panZoom area projection that extends beyond the right/bottom edge of the image -- the extended part of the box will be transparent.

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:


A panZoom area projection and a set of animations that move the panZoom area across the source image.

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.

4.14 Appendices

This section is informative.

4.14.1 Appendix A: Changes to SMIL 1.0 Media Object Attributes

clipBegin, clipEnd, clip-begin, clip-end

With regards to the clipBegin/clip-begin and clipEnd/clip-end elements, SMIL 3.0 defines the following changes to the syntax defined in SMIL 1.0:

Handling of clipBegin/clipEnd syntax in SMIL 1.0 software

Using attribute names with hyphens such as clip-begin and clip-end is problematic when using a scripting language and the DOM to manipulate these attributes. Therefore, this specification adds the attribute names clipBegin and clipEnd as an equivalent alternative to the SMIL 1.0 clip-begin and clip-end attributes. The attribute names with hyphens are deprecated.

Authors may use two approaches for writing SMIL 3.0 presentations that use the new clipping syntax and functionality ("marker", default metric) defined in this specification, but can still can be handled by SMIL 1.0 software. First, authors may use non-hyphenated versions of the new attributes that use the new functionality, and add SMIL 1.0 conformant clipping attributes later in the text.

Example:

<audio src="radio.wav" clipBegin="marker=song1" clipEnd="marker=moderator1" 
       clip-begin="npt=0s" clip-end="npt=3:50" />

SMIL 1.0 players implementing the recommended extensibility rules of SMIL 1.0 [SMIL10] will ignore the clip attributes using the new functionality, since they are not part of SMIL 1.0. SMIL 3.0 players, in contrast, will ignore the clip attributes using SMIL 1.0 syntax, because the SMIL 3.0 syntax takes precedence over the SMIL 1.0 syntax.

The second approach is to use the following steps:

  1. Add a "system-required" test attribute to media object elements using the new functionality. The value of the "system-required" attribute would correspond to a namespace prefix whose namespace IR ([IRI] ) points to a SMIL specification which integrates the new functionality.
  2. Add an alternative version of the media object element that conforms to SMIL 1.0
  3. Include these two elements in a "switch" element

Example:

<smil xmlns="http://www.w3.org/ns/SMIL" version="3.0" baseProfile="Language">
...
<switch>
  <audio src="radio.wav" clipBegin="marker=song1" clipEnd="marker=moderator1" 
   system-required="smil2" />
  <audio src="radio.wav" clip-begin="npt=0s" clip-end="npt=3:50" />
</switch>

Additional Accessibility Attributes

readIndex
Allows explicit ordering for controlling assistive technology.

Additional Advanced Media Attributes

mediaRepeat
The mediaRepeat attribute was added to provide better timing control over media with intrinsic repeat behavior (such as animated GIFs).
erase
Provides a way for visual media to remain visible throughout the duration of a presentation by overriding the default erase behavior.

5. SMIL 3.0 Timing and Synchronization

Editor for SMIL 3.0
Sjoerd Mullender, CWI
Editor for Earlier Versions of SMIL
Dick Bulterman, CWI/Amsterdam
Patrick Schmitz, Microsoft
Jeff Ayars, RealNetworks
Bridie Saccocio, RealNetworks
Muriel Jourdan, INRIA.

5.1 Overview and Summary of Changes for SMIL 3.0

This section is informative.

The SMIL 3.0 specification leaves the basic syntax and semantics of the SMIL 2.1 timing model unchanged [SMIL21-timing]. The only change for SMIL 3.0 are that the four DOM method calls which were reserved in SMIL 2.1 have now been defined. A new module, DOMTimingMethods, was added which contains these DOM methods.

In addition to these changes, various typos were corrected and some clarifications were added.

5.2 Introduction

This section is informative

SMIL 1.0 solved fundamental media synchronization problems and defined a powerful way of choreographing multimedia content. SMIL 2.0 extends the timing and synchronization support, adding capabilities to the timing model and associated syntax. SMIL 3.0 adds Document Object Model support. Some SMIL 1.0 syntax has been changed or deprecated. This section of the document specifies the Timing and Synchronization module.

There are two intended audiences for this module: implementers of SMIL 3.0 document viewers or authoring tools, and authors of other XML languages who wish to integrate timing and synchronization support. A language with which this module is integrated is referred to as a host language. A document containing SMIL Timing and Synchronization elements and attributes is referred to as a host document.

As this module is used in different profiles (i.e. host languages), the associated syntax requirements may vary. Differences in syntax should be minimized as much as is practical.

SMIL 3.0 Timing and Synchronization support is broken down into 17 modules, allowing broad flexibility for language designers integrating this functionality. These modules are described in Appendix A: SMIL Timing and Synchronization modules.

5.3 Overview of SMIL timing

This section is informative

SMIL Timing defines elements and attributes to coordinate and synchronize the presentation of media over time. The term media covers a broad range, including discrete media types such as still images, text, and vector graphics, as well as continuous media types that are intrinsically time-based, such as video, audio and animation.

Three synchronization elements support common timing use-cases:

These elements are referred to as time containers. They group their contained children together into coordinated timelines.

SMIL Timing also provides attributes that may be used to specify an element's timing behavior. Elements have a begin, and a simple duration. The begin may be specified in various ways - for example, an element may begin at a given time, or based upon when another element begins, or when some event (such as a mouse click) happens. The simple duration defines the basic presentation duration of an element. Elements may be defined to repeat the simple duration, a number of times or for an amount of time. The simple duration and any effects of repeat are combined to define the active duration. When an element's active duration has ended, the element may either be removed from the presentation or frozen (held in its final state), e.g. to fill any gaps in the presentation.

An element becomes active when it begins its active duration, and becomes inactive when it ends its active duration. Within the active duration, the element is active, and outside the active duration, the element is inactive.

Figure 1 illustrates the basic support of a repeating element within a simple <par> time container. The corresponding syntax is included with the diagram.

Basic strip illustration of timing

<par begin="0s" dur="33s">
   <video begin="1s" dur="10s" repeatCount="2.5" fill="freeze" .../>
</par>

Figure 1 - Strip diagram of basic timing support. The starred "Simple*" duration indicates that the simple duration is partial (i.e. it is cut off early).

The attributes that control these aspects of timing may be applied not only to media elements, but to the time containers as well. This allows, for example, an entire sequence to be repeated, and to be coordinated as a unit with other media and time containers. While authors may specify a particular simple duration for a time container, it is often easier to leave the duration unspecified, in which case the simple duration is defined by the contained child elements. When an element does not specify a simple duration, the time model defines an implicit simple duration for the element. For example, the implicit simple duration of a sequence is based upon the sum of the active durations of all the children.

Each time container also imposes certain defaults and constraints upon the contained children. For example in a <seq>, elements begin by default right after the previous element ends, and in all time containers, the active duration of child elements is constrained not to extend past the end of the time container's simple duration. Figure 2 illustrates the effects of a repeating <par> time container as it constrains a <video> child element.

More complex strip illustration of timing

<par begin="0s" dur="12s" repeatDur="33s" fill="freeze" >
   <video begin="1s" dur="5s" repeatCount="1.8" fill="freeze" .../>
</par>

Figure 2 - Strip diagram of time container constraints upon child elements. The starred "Simple*" durations indicate that the simple duration is partial (i.e. it is cut off early).

The SMIL Timing Model defines how the time container elements and timing attributes are interpreted to construct a time graph. The time graph is a model of the presentation schedule and synchronization relationships. The time graph is a dynamic structure, changing to reflect the effect of user events, media delivery, and DOM control of the presentation. At any given instant, the time graph models the document at that instant, and the semantics described in this module. However, as user events or other factors cause changes to elements, the semantic rules are re-evaluated to yield an updated time graph.

When a begin or end value refers to an event, or to the begin or active end of another element, it may not be possible to calculate the time value. For example, if an element is defined to begin on some event, the begin time will not be known until the event happens. Begin and end values like this are described as unresolved. When such a time becomes known (i.e. when it can be calculated as a presentation time), the time is said to be resolved. A resolved time is said to be definite if it is not the value "indefinite". See also the discussion of Unifying scheduled and interactive timing.

In an ideal environment, the presentation would perform precisely as specified. However, various real-world limitations (such as network delays) may influence the actual playback of media. How the presentation application adapts and manages the presentation in response to media playback problems is termed runtime synchronization behavior. SMIL includes attributes that allow the author to control the runtime synchronization behavior for a presentation.

5.4 Language definition

This section is normative

5.4.1 Changes for SMIL 3.0

This section is informative

This section remains largely unchanged for SMIL 3.0 except for the relaxation of the restrictions on the begin attributes of children of a seq time container. Also, a number of examples have been added.

5.4.2 Overview

This section is informative

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

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

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

This section is informative

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

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

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

This section is informative

Children of a par begin by default when the par begins (equivalent to begin="0s"). Children of a seq begin by default when the previous child ends its active duration (equivalent to begin="0s"); the first child begins by default when the parent seq begins. Children of an excl default to a begin value of "indefinite".

The begin value may specify a list of times. This can be used to specify multiple "ways" or "rules" to begin an element, e.g. if any one of several events is raised. A list of times may also define multiple begin times, allowing the element to play more than once (this behavior can be controlled, e.g. to only allow the earliest begin to actually be used - see also the restart attribute).

In general, the earliest time in the list determines the begin time of the element. There are additional constraints upon the evaluation of the begin time list, detailed in Evaluation of begin and end time lists.

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

When a begin time is specified as a syncbase variant, a marker value or a wallclock value, the defined time must be converted by the implementation to a time that is relative to the parent time container (i.e. to the equivalent of an offset value). This is known as timespace conversion, and is detailed in the section Converting between local and global times.

Handling negative offsets for begin

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

This section is informative

The use of negative offsets to define begin times merely defines the synchronization relationship of the element. It does not in any way override the time container constraints upon the element, and it cannot override the constraints of presentation time.

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

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

The video element cannot begin before the par begins. The begin is simply defined to occur "in the past" when the par begins. The viewer will observe that the video begins 5 seconds into the media, and ends after 5 seconds. Note that the audio element begins relative to the video begin, and that the computed begin time is used, and not the observed begin time as constrained by the parent. Thus the audio begins 3 seconds into the media, and also lasts 5 seconds.

The behavior can be thought of as a clipBegin value applied to the element, that only applies to the first iteration of repeating elements. In the example above, if either element were defined to repeat, the second and later iterations of the media would play from the beginning of the media (see also the repeatCount, repeatDur, and repeat attributes: repeating elements).

This section is informative

The behavior can be thought of as a clipBegin value applied to the element, that only applies to the first iteration of repeating elements.

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

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

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

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

This section is informative

Thus for example:

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

The element begins when the user activates (for example, clicks on) the element "foo". Its calculated begin time is actually 8 seconds earlier, and so it begins to play at 2 seconds into the 3 second simple duration, on the third repeat iteration. One second later, the fourth iteration of the element will begin, and the associated repeat event will have the Iteration value set to 3 (since it is zero based). The element will end 22 seconds after the activation. The beginEvent event is raised when the element begins, but has a time stamp value that corresponds to the defined begin time, 8 seconds earlier. Any time dependents are activated relative to the computed begin time, and not the observed begin time.

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

Negative begin delays

This section is informative

A begin time specifies a synchronization relationship between the element and the parent time container. Syncbase variants, eventbase, marker and wallclock timing are implicitly converted to an offset on the parent time container, just as an offset value specifies this directly. For children of a seq, the result is always a positive offset from the begin of the seq time container. However, for children of par and excl time containers the computed offset relative to the parent begin time may be negative.

Note that an element cannot actually begin until the parent time container begins. An element with a negative time delay behaves as if it had begun earlier.

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

Dur value semantics

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

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

If there is any error in the argument value syntax 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.

This section is informative

The implicit duration depends upon the type of an element. The primary distinction is between different types of media elements and time containers. If the media element has no timed children, it is described as a simple media element.

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

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

This section is informative

Note that when the simple duration is "indefinite", some simple use cases can yield surprising results. See the related example #4 in Appendix B.

Examples

This section is informative

The following example shows simple offset begin timing. The <audio> element begins 5 seconds after the <par> time container begins, and ends 4 seconds later.

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

The following example shows syncbase begin timing. The <img> element begins 2 seconds after the <audio> element begins.

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

Elements may also be specified to begin in response to an event. In this example, the image element begins (appears) when the user clicks on element "show". The image will end (disappear) 3 and a half seconds later.

<smil ...>
...
<text 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.

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

This section is informative

If an end attribute is specified but none of dur, repeatCount and repeatDur are specified, the simple duration is defined to be indefinite, and the end value constrains this to define the active duration. The behavior of the simple duration in this case is defined in Dur value semantics, as though dur had been specified as "indefinite".

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

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

This section is informative

The end value may specify a list of times. This can be used to specify multiple "ways" or "rules" to end an element, e.g. if any one of several events is raised. A list of times may also define multiple end times that may correspond to multiple begin times, allowing the element to play more than once (this behavior can be controlled - see also the restart attribute).

In the following example, the dur attribute is not specified, and so the simple duration is defined to be the implicit media duration. In this case (and this case only) the value of end will extend the active duration if it specifies a duration greater than the implicit duration. The video will be shown for 8 seconds, and then the last frame will be shown for 2 seconds.

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

If an author wishes to specify the implicit duration as well as an end constraint, the dur attribute may be specified as "media". In the following example, the element will end at the earlier of the intrinsic media duration, or a mouse click:

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

These cases arise from the use of negative offsets in the sync-base and event-base forms, and authors should be aware of the complexities this can introduce. See also Handling negative offsets for end.

In the following example, the active duration will end at the earlier of 10 seconds, or the end of the "foo" element. This is particularly useful if "foo" is defined to begin or end relative to an event.

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

In the following example, the active duration will end at 10 seconds, and will cut short the simple duration defined to be 20 seconds. The effect is that only the first half of the element is actually played. For a simple media element, the author could just specify this using the dur attribute. However in other cases, it is sometimes important to specify the simple duration independent of the active duration.

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

In the following example, the element begins when the user activates (e.g., clicks on) the "gobtn" element. The active duration will end 30 seconds after the parent time container begins.

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

Note that if the user has not clicked on the target element before 30 seconds elapse, the element will never begin. In this case, the element has no active duration and no active end.

The defaults for the event syntax make it easy to define simple interactive behavior. The following example stops the image when the user clicks on the element.

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

Using end with an event value enables authors to end an element based on either an interactive event or a maximum active duration. This is sometimes known as lazy interaction.

In this example, a presentation describes factory processes. Each step is a video, and set to repeat 3 times to make the point clear. Each element may also be ended by clicking on the video, or on some element "next" that indicates to the user that the next step should be shown.

<smil ...>
...
<seq>
  <video dur="5s" repeatCount="3" end="activateEvent; next.activateEvent" .../>
  <video dur="5s" repeatCount="3" end="activateEvent; next.activateEvent" .../>
  <video dur="5s" repeatCount="3" end="activateEvent; next.activateEvent" .../>
  <video dur="5s" repeatCount="3" end="activateEvent; next.activateEvent" .../>
  <video dur="5s" repeatCount="3" end="activateEvent; next.activateEvent" .../>
</seq>
...
</smil>

In this case, the active end of each element is defined to be the earlier of 15 (5s dur * 3 repeats) seconds after it begins, or a click on "next". This lets the viewer sit back and watch, or advance the presentation at a faster pace.

Handling negative offsets for 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.

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

If there is any error in the argument value syntax 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.

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

If there is any error in the argument value syntax 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:

This section is informative

The following examples illustrate some simple use cases for min and max attributes:

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

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

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

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

Example 3. In the following example, if an activate event happens on element "foo" at 5 seconds, this event does not end the time container immediately, but rather at 12 seconds. The simple duration is defined to be "indefinite" (because an end attribute is specified with no dur attribute), and so the time container plays normally until it ends at 12 seconds.

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

Example 4. In the following example, if a click event happens on the first video at 5 seconds, then the simple duration of the time container is computed as 5 seconds. Respecting the fill attribute in the time between the end of the simple duration and the end of the active duration, the two videos are frozen between 5 seconds and 12 seconds.

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

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

<par dur="5s" min="12s" >
   <video xml:id="video_of_15s" .../>
   <video xml:id="video_of_10s" .../>
</par>
The min attribute and negative begin times

This section is informative

If an element is defined to begin before its parent (e.g. with a simple negative offset value), the min duration is measured from the calculated begin time not the observed begin (see example 1 below). This means that the min value may have no observed effect (as in example 2 below).

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

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

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

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

See also the sections The min attribute and restart and Time container constraints on child durations.

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

This section is informative

This approach allows implementations to treat the tokens wallclock and indefinite as reserved element IDs, and begin, end and marker as reserved event names, while retaining an escape mechanism so that elements and events with those names may be referenced.

Clock values

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

This section is informative

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

The following are examples of legal clock values:

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

This section is informative

For example:

00.5s = 500 milliseconds
00:00.005 = 5 milliseconds
Offset values

This section is informative

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

An offset value has the following syntax:

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

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

SMIL 1.0 begin and end values

This section is informative

Deprecated.

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

ID reference values are references to the value of an "id" attribute 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                ::= "\"

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

This section is informative

The semantics of ignored elements may change in a future version of SMIL. One possible semantic is that the associated sync arc arguments will not be invalid, but will instead always be "unresolved". When this behavior needs to be simulated in this version of SMIL Timing and Synchronization, an author may include the value "indefinite" in the list of values for the begin or end attribute.

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

This section is informative

Examples

begin="x.end-5s" : Begin 5 seconds before "x" ends
begin=" x.begin " : Begin when "x" begins
end="x.begin + 1min" : End 1 minute after "x" begins

Event values

An Event value starts with an Eventbase-element 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.

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

This section is informative

This module defines several events that may be included in the supported set for a host language, including beginEvent and endEvent. These should not be confused with the syncbase time values. See the section on Events and event model.

The semantics of event-based timing are detailed in Unifying Scheduling and Interactive Timing. Constraints on event sensitivity are detailed in Event sensitivity.

Examples:

begin=" x.load " : Begin when "load" is observed on "x"
begin="x.focus+3s" : Begin 3 seconds after a "focus" event on "x"
begin="x.endEvent+1.5s" : Begin 1 and a half seconds after an "endEvent" event on "x"
begin="x.repeat" : Begin each time a repeat event is observed on "x"

The following example describes a qualified repeat eventbase value:

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

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

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.

This section is informative

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

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

This section is informative

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

Media-Marker-value ::= Id-value ".marker(" S? Marker-name S? ")"
Marker-name        ::= (Char - ")")+
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 )

This section is informative

Complete date plus hours and minutes:

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

Complete date plus hours, minutes and seconds:

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

Complete date plus hours, minutes, seconds and a decimal fraction of a second

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

Note that the Minutes, Seconds, Fraction, 2DIGIT and DIGIT syntax is as defined for Clock-values. Note that white space is not allowed within the date and time specification.

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.

This section is informative

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

This section is informative

Note that the resulting begin or end time may be before the begin, or after end of the parent time container. This is not an error, but the time container constraints still apply. In any case, the semantics of the begin and end attribute govern the interpretation of the wallclock value.

Examples

This section is informative

The following examples all specify a begin at midnight on January 1st 2000, UTC:

begin="wallclock( 2000-01-01T00:00Z )"
begin="wallclock( 2000-01-01T00:00:00Z )"
begin="wallclock( 2000-01-01T00:00:00.0Z )"
begin="wallclock( 2000-01-01T00:00:00.0Z )"
begin="wallclock( 2000-01-01T00:00:00.0-00:00 )"

The following example specifies a begin at 3:30 in the afternoon on July 28th 1990, in the Pacific US time zone:

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

The following example specifies a begin at 8 in the morning wherever the document is presented:

begin="wallclock( 08:00 )"

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.

This section is informative

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

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

Semantics of endsync and dur and end:

Semantics of endsync and restart:

Semantics of endsync and paused elements:

This section is informative

Semantics of endsync and unresolved child times:

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

This section is informative

SMIL 1.0 introduced the repeat attribute, which is used to repeat a media element or an entire time container. SMIL 2.0 introduces two new controls for repeat functionality that supersede the SMIL 1.0 repeat attribute. The new attributes, repeatCount and repeatDur, provide a semantic that more closely matches typical use-cases, and the new attributes provide more control over the duration of the repeating behavior.

Repeating an element causes the simple duration to be "played" several times in sequence. This will effectively copy or loop the contents of the element media (or an entire timeline in the case of a time container). The author may specify either how many times to repeat, using repeatCount, or how long to repeat, using repeatDur. Each repeat iteration is one instance of "playing" the simple duration.

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

This section is informative

Examples

This section is informative

In the following example, the implicit duration of the audio is constrained by repeatCount. Only the first half of the clip will play; the active duration will be 1.5 seconds.

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

In this example, the 3 second (implicit) simple duration will be played three times through and then is constrained by the dur attribute on the parent par; the active duration will be 9 seconds.

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

In the following example, the 2.5 second simple duration will be repeated twice; the active duration will be 5 seconds.

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

In the following example, the 3 second (implicit) simple duration will be repeated two full times and then the first half is repeated once more; the active duration will be 7.5 seconds.

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

In the following example, the audio will repeat for a total of 7 seconds. It will play fully two times, followed by a fractional part of 2 seconds. This is equivalent to a repeatCount of 2.8.

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

Note that if the simple duration is indefinite, repeat behavior is not defined (but repeatDur still contributes to the active duration). In the following example the simple duration is 0 and indefinite respectively, and so the repeatCount is ignored. Nevertheless, this is not considered an error. The active duration is equal to the simple duration: for the first element, the active duration is 0, and for the second element, the active duration is indefinite.

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

In the following example, the simple duration is 0 for the image and indefinite for the text element, and so repeat behavior is not meaningful. The active duration is 0 for the first element, however for the second element, the active duration is determined by the repeatDur value, and so is 10 seconds. The effect is that the text is shown for 10 seconds.

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

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

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

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

<seq begin="5s" repeatCount="3" >
   <img src="img1.jpg" dur="5s" />
   <img src="img2.jpg" dur="4s" />
   <img src="img3.jpg" dur="4s" />
</seq>
The min attribute and restart:

This section is informative

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

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

This section is informative

The SMIL 1.0 repeat attribute behaves in a manner similar to repeatCount, but it defines the functionality in terms of a sequence that contains the specified number of copies of the element without the repeat attribute. This definition has caused some confusion among authors and implementers. See also the SMIL 1.0 specification [SMIL10].

In particular, there has been confusion concerning the behavior of the SMIL 1.0 end attribute when used in conjunction with the repeat attribute. SMIL 3.0 complies with the common practice of having the end attribute define the element's simple duration when the deprecated repeat attribute is used. Only SMIL document user agents must support this semantic for the end attribute. Only a single SMIL 1.0 "end" value (i.e. an Offset-value or a SMIL-1-syncbase-value, but none of the new SMIL 2.0 timing) is permitted when used with the deprecated repeat attribute. If repeat is used with repeatCount or repeatDur on an element, or if repeat is used with an illegal end value, the repeat value is ignored.

repeat
This attribute has been deprecated in SMIL 2.0 in favor of the new repeatCount and repeatDur attributes.
This causes the element to play repeatedly for the specified number of times. It is equivalent to a seq element with the stated number of copies of the element without the "repeat" attribute as children. All other attributes of the element, including any begin delay, are included in the copies.
Legal values are integer iterations, greater than 0, and "indefinite".

The fill attribute: extending an element

This section is informative

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

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

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.

This section is informative

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

fill = ( "remove" | "freeze" | "hold" | "transition" | "auto" | "default" )
This attribute may have the following values:
remove
Specifies that the element will not extend past the end of the last instance of the simple duration.
freeze
Specifies that the element will extend past the end of the last instance of the simple duration by "freezing" the element state at that point. The parent time container of the element determines how long the element is frozen (as described immediately below).
hold
Setting this to "hold" has the same effect as setting to "freeze", except that the element is always frozen to extend to the end of the simple duration of the parent time container of the element (independent of the type of time container). For profiles that support a layered layout model (e.g., SMIL 3.0 Language Profile), held elements (elements with fill="hold") will refresh their display area when a layer is added on top then later removed.
transition
Setting this to "transition" has the same effect as setting to "freeze", except that the element is removed at the end of the transition. This value is only allowed on elements with media directly associated with them. If specified on any other element (e.g. a time container element in the SMIL language profile), the attribute is ignored. See the SMIL Transitions module.
auto
The fill behavior for this element depends on whether the element specifies any of the attributes that define the simple or active duration:
  • If none of the attributes dur, end, repeatCount or repeatDur are specified on the element, then the element will have a fill behavior identical to that if it were specified as "freeze".
  • Otherwise, the element will have a fill behavior identical to that if it were specified as "remove".
default
The fill behavior for the element is determined by the value of the fillDefault attribute.
This is the default value.
If the application of fillDefault to an element would result in the element having a value of fill that is not allowed on that element, the element will instead have a fill value of "auto".

This section is informative.

Note that given the default values for fill and fillDefault attributes, if the fill attribute is not specified for an element, and if the fillDefault attribute is not specified for any ascendant of the element, the behavior uses "auto" semantics.

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

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
fillDefault = ( "remove" | "freeze" | "hold" | "transition" | "auto" | "inherit" )
Defines the default value for the fill behavior for an element and all descendants.
The values "remove", "freeze", "hold", "transition" and "auto" specify that the element fill behavior is the respective value.
inherit
Specifies that the value of this attribute (and of the fill behavior) are inherited from the fillDefault value of the parent element. If there is no parent element, the value is "auto".
This is the default value.
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].

This section is informative

The fill attribute may be used to maintain the value of a media element after the active duration of the element ends:

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

The video element ends 35 seconds after the parent time container began, but the video frame at 30 seconds into the media remains displayed until the audio element ends. The attribute "freezes" the last value of the element for the remainder of the time container's simple duration.

This functionality is also useful to keep prior elements on the screen while the next item of a seq time container prepares to display as in this example:

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

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

The restart attribute

This section is informative

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

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

For the precise definition of when restart semantics apply, see the section Evaluation of begin and end time lists.

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

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.

This section is informative.

For details on when and how the restart attribute is evaluated, see Evaluation of begin and end time lists.

Using restart for toggle activation

This section is informative

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

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

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

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

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

This is based upon the event sensitivity semantics described in Event sensitivity and Unifying Scheduling and Interactive Timing.

Controlling the default behavior of restart

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

restartDefault = ( "always" | "whenNotActive" | "never" | "inherit" )
Defines the behavior of the restart attribute when its value is "default".
The values "always", "whenNotActive" and "never" specify that the element restart behavior is the respective value.
inherit
Specifies that the value of this attribute (and of the restart behavior) are inherited from the restartDefault value of the parent element. If there is no parent element, the value is "always".
This is the default value.

This section is informative.

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

Resetting element state

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

  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.

This section is informative

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

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

This section is informative

New support in SMIL 2.0 introduces finer grained control over the runtime synchronization behavior of a document. The syncBehavior attribute allows an author to describe for each element whether it must remain in a hard sync relationship to the parent time container, or whether it may be allowed slip with respect to the time container. Thus, if network congestion delays or interrupts the delivery of media for an element, the syncBehavior attribute controls whether the media element may slip while the rest of the document continues to play, or whether the time container must also wait until the media delivery catches up.

The syncBehavior attribute may also be applied to time containers. This controls the sync relationship of the entire timeline defined by the time container. In this example, the audio and video elements are defined with hard or "locked" sync to maintain lip sync, but the "speech" par time container is allowed to slip:

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

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

This functionality also applies when an element first begins, 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 syncBehavior attribute controls whether the time container must wait until the element media is ready, or whether the element begin may slip until the media is downloaded.

An additional extension allows the author to specify that a particular element should define or control the synchronization for a time container. This is similar to the default behavior of many user agents that "slave" video and other elements to audio, to accommodate the audio hardware inaccuracies and the sensitivity of listeners to interruptions in the audio playback. The syncMaster attribute allows an author to explicitly define that an element defines the playback "clock" for the time container, and all other elements should be held in sync relative to the syncMaster element.

In practice, linear media often need to be the syncMaster, where non-linear media can more easily be adjusted to maintain hard sync. However, a user agent cannot always determine which media behaves in a linear fashion and which media behaves in a non-linear fashion. In addition, when there are multiple linear elements active at a given point in time, the user agent cannot always make the "right" decision to resolve sync conflicts. The syncMaster attribute allows the author to specify the element that has linear media, or that is "most important" and should not be compromised by the syncBehavior of other elements.

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

The argument value independent is equivalent to setting syncBehavior="canSlip" and syncMaster="true" so that the element is scheduled within the timegraph, but is unaffected by any other runtime synchronization issues. Setting syncBehavior="canSlip" and syncMaster="true" declares the element as being the synchronization master clock and that the element may slip against its parent time line

syncTolerance = ( Clock-value | "default" )
This attribute on timed elements and time containers defines the synchronization tolerance for the associated element . The attribute has an effect only if the element's runtime synchronization behavior is "locked". This allows a locked sync relationship to ignore a given amount of slew without forcing resynchronization.
Clock-value
Specifies the synchronization tolerance as a value. Clock values are measured in element simple time.
default
The synchronization tolerance for the element is determined by the value of the syncToleranceDefault attribute.
This is the default value.
syncMaster = ( "true" | "false" )
Boolean attribute on media elements and time containers that forces other elements in the time container to synchronize their playback to this element.
The default value is false.

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 the syncTolerance attribute. This specifies the amount of slip that may be ignored for an element. Small variance in media playback (e.g. due to hardware inaccuracies) can often be ignored, to 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.

Controlling the default behavior

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

syncBehaviorDefault = ( "canSlip" | "locked" | "independent" | "inherit" )
Defines the behavior of the syncBehavior attribute when its value is "default".
The values "canSlip", "locked" and "independent" specify that the element's runtime synchronization behavior is the respective value.
inherit
Specifies that the value of this attribute (and the value of the element's runtime synchronization behavior) are inherited from the syncBehaviorDefault value of the parent element. If there is no parent element, the value is implementation dependent.
This is the default value.
syncToleranceDefault = ( Clock-value | "inherit" )
Defines the behavior of the syncTolerance attribute when its value is "default".
Clock values specify that the element's runtime synchronization tolerance value is the respective value.
inherit
Specifies that the value of this attribute (and the value of the element's runtime synchronization tolerance value) are inherited from the syncToleranceDefault value of the parent element. If there is no parent element, the value is implementation dependent but should be no greater than two seconds.
This is the default value.
The accumulated synchronization offset

If an element slips synchronization relative to its parent, the amount 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 tc(tps) be the computed element active time for an element at the parent simple time tps, according to the defined synchronization relationship for the element.

Let to(tps) be the observed element active time for an element at the parent simple time tps.

The accumulated synchronization offset O is:

O = to(tps) - tc(tps)

This offset is measured in parent simple time.

This section is informative.

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.

Attributes for timing integration: timeContainer and timeAction

This section is informative

The modularization of SMIL 3.0 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 may 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. The timeContainer attribute allows the author to specify that any XML language element has time container behavior. E.g., an HTML <ol> ordered list element may be defined to behave as a sequence time container. The timeAction attribute allows the author to specify what it means to apply timing to a given element.

The timeContainer attribute

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

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

Constraints upon the use of the timeContainer attribute are:

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:

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

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:

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:

This section is informative.

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

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 smil:timeAction="visibility" smil:begin="3s" smil:dur="5s">
   Show this text for a short period.
</span>
      

The following example shows a simple case of controlling display 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 smil:timeContainer="seq" smil:repeatDur="indefinite">
   <li smil:timeAction="display" smil:dur="5s">
      This is the first thing you will see. </li>
   <li smil:timeAction="display" smil:dur="5s">
      You will see this second. </li>
   <li smil:timeAction="display" smil:dur="5s">
      Last but not least, you will see this. </li>
</ol>
      

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

<form ...>
...
   <label for="select_red" smil:begin="focus" smil:dur="5s" smil:timeAction="style"
          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

This section is informative

SMIL 3.0 specifies three types of time containers. These may be declared with the elements par, seq, and excl, or in some integration profiles with a timeContainer attribute. Media elements with timed children are defined to be "media time containers", and have semantics based upon the par semantics (see also Attributes for timing integration: timeContainer and timeAction and Implicit 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.

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

This section is informative.

This is the same element introduced with SMIL 1.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.

This section is informative.

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

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

This section is informative.

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

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.

This section is informative

With the excl time container, common use cases that were either difficult, or impossible, to author are now easier and possible to create. The excl time container is used to define a mutually exclusive set of clips, and to describe pausing and resuming behaviors among these clips. Examples include:

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

The interactive playlist use case above could be accomplished using a par whose sources have interactive begin times and end events for all other sources. This would require a prohibitively long list of values for end to maintain. The excl time container provides a convenient short hand for this - the element begin times are still interactive, but the end events do not need to be specified because the excl, 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 by excl and priorityClass. This use case would be authored with a video and each audio description as children of the excl. The video element would be scheduled to begin when the excl 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 of excl. 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 xml:id="vid1" .../>
   <excl dur="indefinite">
      <par begin="englishBtn.activateEvent" >
         <audio begin="vid1.begin" src="english.au" />
      </par>
      <par begin="frenchBtn.activateEvent" >
         <audio begin="vid1.begin" src="french.au" />
      </par>
      <par begin="swahiliBtn.activateEvent" >
         <audio begin="vid1.begin" src="swahili.au" />
      </par>
   </excl>
</par>
...
</smil>

The three par elements are children of the excl, and so only one can play at a time. The audio child in each par 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 each par begins, the audio will start playing at some point in the middle of the audio clip, and in sync with the video.

The excl time container is useful in many authoring scenarios by providing a declarative means of describing complex clip interactions.

Implicit duration of excl containers
The priorityClass element

This section is informative

Using priority classes to control the pausing behavior of children of the excl 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 element priorityClass describe the intended interactions.

Each priorityClass element describes a group of children, and the behavior of those children when interrupted by other time-children of the excl. The behavior is described in terms of peers, and higher and lower priority elements. Peers are those elements within the same priorityClass element.

When one element within the excl 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.

priorityClass
Defines a group of excl time-children, and the pause/interrupt behavior of the children. If a priorityClass element appears as the child of an excl, then the excl must only contain priorityClass elements (i.e. the author must not mix timed children and priorityClass elements within an excl).

If no priorityClass element is used, all the children of the excl are considered to be peers, with the default peers behavior "stop".

The peers, higher, and lower attributes

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

peers = ( "stop" | "pause" | "defer" | "never" )
Controls how child elements of this priorityClass will interrupt one another.
Legal values for the attribute are:
stop
If a child element begins while another child element is active, the active element is simply stopped.
This is the default for peers.
pause
If a child element begins while another child element is active, the active element is paused and will resume when the new (interrupting) element completes its active duration (subject to the constraints of the excl time container). The paused element is added to the pause queue.
defer
If a child element attempts to (i.e. would normally) begin while another child element is active, the new (interrupting) element is deferred until the active element completes its active duration.
never
If a child element attempts to (i.e. would normally) begin while another child element is active, the new (interrupting) element is prevented from beginning. The begin of the new (interrupting) element is ignored.
higher = ( "stop" | "pause" )
Controls how elements with higher priority will interrupt child elements of this priorityClass.
Legal values for the attribute are:
stop
If a higher priority element begins while a child element of this priorityClass is active, the active child element is simply stopped.
pause
If a higher priority element begins while a child element of this priorityClass is active, the active child element is paused and will resume when the new (interrupting) element completes its active duration (subject to the constraints of the excl time container). The paused element is added to the pause queue.
This is the default for the higher attribute.
lower = ( "defer" | "never" )
Controls how elements defined with lower priority will interrupt child elements of this priorityClass.
Legal values for the attribute are:
defer
If a lower priority element attempts to (would normally) begin while a child element of this priorityClass is active, the new (interrupting) element is deferred until the active element completes its active duration. The rules for adding the element to the queue are described below.
This is the default for the lower attribute.
never
If a lower priority element attempts to begin while a child element of this priorityClass is active, the new (interrupting) element is prevented from beginning. The begin of the new (interrupting) element is ignored, and it is not added to the queue.

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

The pauseDisplay attribute

This section is informative

The pauseDisplay attribute controls the behavior when paused of the children of a priorityClass element. When a child of a priorityClass element is paused according to excl and priorityClass semantics, the pauseDisplay attribute controls whether the paused element will continue to show or apply 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.

pauseDisplay = ( "disable" | "hide" | "show" )
Controls how child elements of the priorityClass element behave when paused. This attribute only applies if peers="pause" or higher="pause".
Legal values for the attribute are:
disable
Continue to display visual media when the element is paused by the excl and priorityClass, but appear disabled. It is implementation dependent how a disabled element appears (rendered in some different way to distinguish from the active state -- e.g., grayed out); disabled elements do not respond to mouse events.
hide
Remove the effect of the element (including any rendering) when the element is paused by the excl and priorityClass semantics.
show
Continue to show the effect of the element (including any rendering) when the element is paused by the excl and priorityClass semantics. This value has no effect on a aural media.
This is the default.
Examples using excl and priorityClass

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 xml:id="song1" .../>
   <audio xml:id="song2" .../>
   <audio xml:id="song3" .../>
   ...
   <audio xml:id="songN" .../>
</excl>

is equivalent to the following with explicit settings:

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

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

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

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

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

This example shows a more complex case of program material and 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 xml:id="ads" peers="defer">
     <video xml:id="advert1" .../>
     <video xml:id="advert2" .../>
   </priorityClass>
   <priorityClass xml:id="program" peers="stop" higher="pause">
     <video xml:id="program1" .../>
     <video xml:id="program2" .../>
     <video xml:id="program3" .../>
     <video xml:id="program4" .../>
   </priorityClass>
</excl>

The following example illustrates how defer semantics and priority groups can interact. When "alert1" tries to begin at 5 seconds, the "program" priorityClass will 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 the peers 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 xml:id="program" lower="defer">
     <video xml:id="prog1" begin="0" dur="20s" .../>
   </priorityClass>
   <priorityClass xml:id="alerts" peers="never">
     <video xml:id="alert1" begin="5s" .../>
     <video xml:id="alert2" begin="6s" .../>
   </priorityClass>
</excl>

This example illustrates pauseDisplay 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 xml:id="video1" .../>
      <video xml:id="video2" .../>
      <video xml:id="video3" .../>
      ...
      <video xml:id="videoN" .../>
   </priorityClass>
</excl>

In this example, when a child of a higher priorityClass 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 xml:id="ads" peers="defer">
      <video xml:id="advert1" .../>
      <video xml:id="advert2" .../>
   </priorityClass>
   <priorityClass xml:id="program" peers="stop" higher="pause" pauseDisplay="show">
      <video xml:id="program1" .../>
      <video xml:id="program2" .../>
      <video xml:id="program3" .../>
      <video xml:id="program4" .../>
   </priorityClass>
</excl>
Pause queue semantics

Elements that are paused or deferred are placed in a priority-sorted 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 is pulled 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 a priorityClass element are considered to have the priority of that priorityClass, and to have the behavior described by the peers, higher and lower attributes on the priorityClass parent.

Queue invariants
  1. The queue is sorted by priority, with higher priority elements before lower priority elements.
  2. An element may not appear in the queue more than once.
  3. An element may not simultaneously be active and in the queue.
Element insertion and removal
  1. Elements are inserted into the queue sorted by priority (by invariant 1).
    1. Paused elements are inserted before elements with the same priority.
    2. Deferred elements are inserted after elements with the same priority.
  2. Where the semantics define that an active element must be paused, the element is paused at the current simple time (position) when placed on the queue. When a paused element is pulled normally from the queue, it will resume from the point at which it was paused.
  3. Where the semantics define that an element must be deferred, the element is inserted in the queue, but is not begun. When the element is pulled normally from the queue, it will begin (i.e. be activated).
  4. When an element is placed in the queue any previous instance of that element is removed from the queue (by invariant 2).
  5. When the active child (i.e. time-child) of an excl ends normally (i.e. not when it is stopped by another, interrupting element), the element on the front of the queue is pulled off the queue, and resumed or begun (according to rule 2 or 3).

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

Runtime synchronization behavior and pause/defer semantics

The runtime synchronization behavior of an element (described in the syncBehavior, syncTolerance, and syncMaster 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.

Calculated times and pause/defer semantics

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.

This section is informative.

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

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

If an element ends while it is in the pause queue, it is simply 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 in Paused elements and the active duration, the begin time of a deferred element may become unresolved, or it may simply be delayed.

This section is informative.

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

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

If there is enough information to determine the 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 the Propagating changes to times section.

This section is informative.

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 the Deferred elements and propagating changes to begin section.

Scheduled begin times and excl

Although the default begin value for children of an excl is indefinite, scheduled begin times are permitted. Scheduled begin times on children of the excl cause the element to begin at the specified time, pausing or stopping other siblings depending on the priorityClass settings (and default values).

Handling Simultaneous Begins within excl

If children of an excl 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 xml:id="img1" src="image1.jpg" begin="foo.activateEvent" dur="5s"/>
   <img xml:id="img2" src="image2.jpg" begin="img1.begin" dur="5s"/>
   <img xml:id="img3" src="image3.jpg" begin="img2.begin" dur="5s"/>
</excl>
...
</smil>

In the first example, the images are scheduled to begin immediately, 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 for excl, 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 the excl begins.

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

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

Note, some surprising results may occur when combining scheduled and interactive timing within an excl. 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 a seq time container.

Side effects of activation

This section is informative

Children of the excl may be activated by scheduled timing, hyperlinks, events or DOM methods calls. For all but hyperlink activation, the excl time container must be active for child elements of the excl to be activated. With hyperlink activation, the document may be seeked to force the parent excl 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 an excl.

With activation via a DOM method call (e.g. the beginElement() method), the element will be activated at the current time (subject to the priorityClass 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 all priorityClass semantics are respected nevertheless.

This section is informative.

See also Hyperlinks and timing and specifically Implications of beginElement() and hyperlinking for seq and excl time containers.

Implicit duration of media element time containers

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 a par 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 by endsync is longer 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.

Examples:

This section is informative.

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

The default value of endsync for media elements is "media", and so the simple duration in the following example is 10 seconds. This will cut short the animate child 8 seconds into its simple duration:

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

Specifying endsync="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>

Specifying endsync="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>

Specifying endsync="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:

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

Thus if the user clicks on the video after 1 second, the simple 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.

Media time containers of other types

This section is informative.

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

The animate children of the video will act in sequence. The endsync semantics define a simple duration for the video 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 the video as soon as the last animate begins.

5.4.5 Semantics of the Timing Model

Resolving times

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 of Event 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 of Event 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 may be unresolved but may become resolved when end conditions are met or the parent time container constrains the element's duration.

Definite times

A resolved time is said to be definite if it is not the value "indefinite".

Defining the simple duration

The simple duration of an element is determined by the dur 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 and repeatCount Simple Duration
unspecified (ignored) unspecified, end specified indefinite
Clock-value (ignored) (ignored) dur or Clock-value
indefinite (ignored) (ignored) indefinite
unspecified resolved (ignored) implicit element duration
or Clock-value
unspecified unresolved (ignored) unresolved
media resolved or unresolved (ignored) implicit element duration

Simple Duration Table

The repeatCount and unresolved simple duration

When repeatCount 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 the repeatCount and 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 the repeatCount to constrain the last simple duration. If the last iteration of the simple duration otherwise ends before this time, the repeatCount should be considered to be complete. If a repeatCount is less than 1 and the simple duration is unresolved, the repeatCount cannot be correctly respected, and will behave as though a repeatCount of "1" were specified.

This section is informative

If an element specifying audio media has a simple duration of 0 (e.g., because of clipBegin and clipEnd values), nothing should be played even if the repeatDur specifies an active duration. The time model behaves according to the description, but no audio should be played.

If a repeatDur is shorter than the simple duration, or if repeatCount is less than 1, the active duration may cut short the defined simple duration.

If repeatDur is "indefinite" and neither of repeatCount or end are specified, the active duration is indefinite. If repeatCount is indefinite, the simple duration is greater than 0 and neither of repeatDur or end are specified, then the active duration is indefinite.

Note that unlike in SMIL 1, when an element defines a begin offset and repeat behavior with repeatCount or repeatDur, the begin offset is not included in each repeat.

Computing the active duration

The active duration of an element defines the entire period that an element's timeline is active. It takes into account the element simple duration evaluated above, the end attribute, and any repeat behavior defined by the repeatDur and repeatCount attributes.

Active duration arithmetic rules

Computing the active duration requires defining arithmetic operations on all of the possible values that simple duration may have.

Multiplication
Addition and Subtraction
Minimization Function

Where anything means zero value, non-zero value, indefinite, or unresolved.

Maximization Function
Active duration algorithm

In this section, references to begin and end values should be understood as the current effective values in each respective value list. These values are determined by the rules described in Evaluation of begin and end time lists.

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

B
The begin of an element.
d
The simple duration of an element.
PAD
The preliminary active duration of an element, before accounting for min and max semantics.
AD
The active duration of an element.

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:

If end is specified, and none of dur, repeatDur, and repeatCount are specified, then the simple duration is indefinite from the simple duration table above, and the active duration is defined by the end value, according to the following cases:

If end is resolved to a value, then PAD = end - B,

else, if end is indefinite, then PAD = indefinite,

else, if end is unresolved, then PAD is unresolved, and needs to be recomputed when more information becomes available.

Else, if no end value is specified, or the end value is specified as indefinite, then the active duration is determined from the Intermediate Active Duration computation given below:

PAD = Result from Intermediate Active Duration Computation

Otherwise, an end value not equal to indefinite is specified along with at least one of dur, repeatDur, and repeatCount. Then the PAD is the minimum of the result from the Intermediate Active Duration Computation given below and duration between end and the element begin:

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

Finally, the computed active duration AD is obtained by applying min and max semantics to the preliminary active duration PAD. In the following expression, if there is no min value, substitute a value of 0, and if there is no max value, substitute a value of "indefinite":

AD = MIN( max, MAX( min, PAD ))
Intermediate Active Duration Computation

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

p0 is the simple duration from the Simple Duration Table, given above.

If repeatCount is not specified, p1 has the value indefinite. 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 of repeatDur. If repeatDur is unspecified, then p2 will have a value of indefinite.

Then IAD is given by:

If p0 equals 0, then

IAD = 0

Else if repeatDur and repeatCount are 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, the end 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 xml:id="mutebutton" src="mute.jpg"/>
   <text  src="description.html" />
   <audio src="audio.au" end="mutebutton.activateEvent"/>
</par>
...
</smil>

The image and the text appear for the specified duration of the par (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, the dur 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:

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

In this case, the active end of each element is defined to be the 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.

Paused elements and the active duration

An element may 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 xml:id="foo" dur="10s" .../>
<img xml:id="bar" 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 the excl pause queue are well defined, the end of "foo" can be computed to be 15 seconds:

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

If there is enough information to determine the new end time (as in 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 the Propagating changes to times section.

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

Finally, when an element is paused it may end because the parent time container ends., 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).

Evaluation of begin and end time lists

This section is informative

Children of par and excl time containers may 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 of intervals 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 one current 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 the conditions 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 may 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 element resets, as described in Resetting 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 may 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 the current 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 the end changes while the current interval is playing, the current interval end will be recomputed and may change. Nevertheless, once a time has happened, 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 given interval of the syncbase element to a particular instance 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.

The instance times lists

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 may have a begin attribute that defines one or more conditions that may 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 may 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 may 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.

Building the instance times lists

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. See Resetting 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 in Interaction 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, a time-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 in End 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 may 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 may 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.

Principles for building and pruning intervals

This section is informative

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 terms pruning and cutting off an interval - these concepts should not be confused.

In some cases, after an interval has been created, it must later be pruned (deleted/removed from the timegraph) as more information becomes known and semantic constraints must be applied. When an interval is pruned, 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 the pruned 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 xml:id="slide1" src="slide1.jpg" dur="3s" />
   <img xml:id="slide2" src="slide2.jpg" begin="slide1.end+3s" dur="10s" />
   <img xml:id="note1" src="note1.jpg" begin="slide1.beginEvent" dur="20s" />
</par>

The "slide1" image will be cut off, but is not pruned. It is cut off because 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 is cut off, Intervals that are cut 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.

The principles underlying the interval life cycle model are:

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

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

Element life-cycle

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

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

Steps 2 to 5 can loop for as many intervals as are defined before the end of the parent simple duration. At any time during step 2, the begin time for the current interval may change, and at any time during steps 2 or 3, the end time for the current interval may 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.

Startup - getting the first 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 generally any ascendant time container) repeats or restarts, the element resets (see also Resetting element state) and starts "life" anew.

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

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

Action 1) is also described in Resetting 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 in End 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:

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

Thus the strict definition of the first acceptable interval for 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 may be a resolved numeric value, the special value INDEFINITE (only used with end), and it may 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 interval
Interval getFirstInterval()
{
Time beginAfter=-INFINITY;

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

Note that while we might consider the case of restart="always" separately from restart="whenNotActive", it would just be busy work since we need to find an interval that begins after tempEnd.

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 a new 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.

Waiting to begin the 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 will add the 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 be pruned 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.

This section is informative.

One exception to normal processing is made for elements that are deferred according to excl interrupt semantics: a deferred element ignores propagated changes to its begin time. This is detailed in the Deferred elements and propagating changes to begin section.

Active time - playing an interval

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 may 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 of adding a new instance time to the begin list, which can cause a restart.

If the element receives a "new interval" notice while it is active, it will add the 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 also Interaction with restart semantics.

End of an interval

If an element specifies restart="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 for restart, 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 the current 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 interval
Interval getNextInterval()
{
// Note that at this point, the just ended interval is still the "current interval"
Time beginAfter=currentInterval.end;

   Set tempBegin = the first value in the begin list that is >= beginAfter.
   If there is no such value  // No interval
      return FAILURE;

   If tempBegin >= parentSimpleEnd // Can't begin after parent ends
      return FAILURE;

   If there was no end attribute specified
      // this calculates the active end with no end constraint
      tempEnd = calcActiveEnd( tempBegin );
   else
   {
      // We have a begin value - get an end
      Set tempEnd = the first value in the end list that is >= tempBegin.
      // Allow for non-0-duration interval that begins immediately
      // after a 0-duration interval.
      If tempEnd == currentInterval.end
      {
         set tempEnd to the next value in the end list that is > tempEnd
      }         
      If there is no such value
      {
         // Events leave the end open-ended. If there are other conditions
         // that have not yet generated instances, they must be unresolved.
         if endHasEventConditions()
            OR if the instance list is empty
            tempEnd = UNRESOLVED;
         // if all ends are before the begin, bad interval
         else
            return FAILURE;
      }
      // this calculates the active dur with an end constraint
      tempEnd = calcActiveEnd( tempBegin, tempEnd );
   }

   return( Interval( tempBegin, tempEnd ) );

} // close getNextInterval
Post active

This period can extend from the end of an interval 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.

Interaction with restart semantics

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

  1. When the current interval is playing, if restart="always" then any instance time (call it T) 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 time T. This is the first step in restarting the element: when the current interval ends, that in turn will create any following interval.
  2. When a new instance time is added to the begin list of instance times, restart rules may apply. The new instance times may result from a begin condition that specifies one of the syncbase value conditions, for which a new instance notice is received. It may also result from a begin condition that specifies one of the event value conditions, for which the associated event happens.
    In either case, the restart setting and the state of the current interval controls the resulting behavior. The new instance time is computed (e.g. from the syncbase current interval time or from the event time, and including any offset), and added to the begin list. Then:
    • If the current interval is waiting to play, the element recalculates the begin and end times for the current interval, as described in the Element life-cycle step 1 (for the first interval) or step 4 (for all later intervals). If either the begin or end time of the current interval changes, these changes must be propagated to time dependents accordingly.
    • If the current interval is playing (i.e. it is active), then the restart setting determines the behavior:
      • If 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.
      • If 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).
      • If restart="always" then case 1 above applies, and will cause the current interval to end.
Cyclic dependencies in the timegraph

There are two types of cycles that can be created with SMIL 3.0, closed cycles and open or propagating cycles. A closed 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. An open or propagating 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.

Detecting Cycles

Implementations can detect cycles in the timegraph using a visited 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 been visited. 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 second chained notice 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.

Examples

This section is informative.

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 xml:id="foo" begin="bar.begin" .../>
<img xml:id="bar" begin="foo.begin" .../>

Example 2: In the following example, the 3 images define a less 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 xml:id="foo" begin="joe.end" .../>
<img xml:id="bar" begin="foo.begin" dur="3s" .../>
<img xml:id="joe" begin="0" end="bar.end" .../>

Example 3: In the following example, the 2 images define begin times 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 xml:id="foo" begin="0; bar.begin+2s" dur="3s" .../>
<img xml:id="bar" begin="foo.begin+2s" dur="3s" .../>

Example 4: In the following example, an open cycle is described 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 xml:id="foo" begin="0; bar.begin-1s" dur="10s" .../>
   <video xml:id="bar" begin="foo.begin-1s" dur="10s" .../>
</par>

Timing and real-world clock times

This section is informative

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

Interval timing

This section is informative

The SMIL timing model assumes the most common model for interval timing.

This section is informative

This is also referred to as end-point exclusive timing. This model makes arithmetic for intervals work correctly, and provides sensible models for sequences of intervals.

Background rationale

This section is informative.

In the real world, this is equivalent to the way that seconds add up 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. They do 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" is also 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.

Implications for the time model

This section is informative.

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 the inclusive begin of the interval. The simple duration proceeds normally up to 4 seconds.

This section is informative.

Using this, a time of 4 (or 8 or 12) maps to the time of 0 on the simple duration. The endpoint of the simple duration is excluded 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.

This section is informative.

The effect of this semantic upon animation functions is detailed in the SMIL 3.0 Animation chapter.

Event sensitivity

This section is informative

The SMIL 3.0 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:

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

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

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 xml:id="bad_example" begin="link9.activateEvent">
   <img begin="link9.activateEvent" .../>
</par>
...
</smil>

Various alternative approaches can be used. One possible approach is to define the descendant 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 xml:id="better_example" begin="link9.activateEvent">
   <img begin="better_example.begin" .../>
</par>
...
</smil>

The event sensitivity rules may 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:

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

This example will begin repeating the audio clip when "foo" is clicked, and stop the audio clip 3 seconds after "foo" is clicked a 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:

<smil ...>
...
<audio src="bounce.wav" begin="foo.activateEvent" dur="3s"
        restart="whenNotActive"/>
...
</smil>
User event sensitivity and timing

The timing model and the user event model are largely orthogonal. 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 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.

Link Activation compared to Event activation

This section is informative.

Related to event-activation is link-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 informative.

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

Converting between local and global times

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.

Element active time calculation

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 in The accumulated synchronization offset).

Let tps be a time in parent simple time, B be the begin time for an element, and O be the accumulated synchronization offset for an element, measured in parent simple time.

The element active time ta for any child element is:

ta = tps - B - O
Element simple time calculation

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 time ts from an element active time ta, accounting for any repeat behavior:

If there is no repeating behavior:
ts = ta

Else, the element simple time is just computed from the begin time of the most recent iteration - call this tlast-repeat. Some other mechanism (such as endsync logic or a media player) must note when the simple duration ends, and reset the value of tlast-repeat. If the element has not yet repeated, a value of 0 is used in place of tlast-repeat.

ts = ta - tlast-repeat

Note that the above semantic covers the special (ideal) case when the simple duration dur is fixed and does not vary. In this case (and this case only) tlast-repeat may be obtained directly for the simple duration dur and so the expression may be reduced to:

ts = REMAINDER( ta, dur )

where REMAINDER( t, d ) is defined as (t - d*floor(t/d)).

Converting wall-clock values

When the document begins, the current wall-clock time is noted and saved as twallclock-begin. To convert a wall-clock value twc to an element active simple time ts, first convert twc to a document global time tra (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 time tra is then converted normally to element active time or element local time as needed.

Converting from event time to element time

Event times are generally stamped with a time relative to system time 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.

Converting from element time to element time

To convert from one element timespace to another, the time for the first element te1 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 of tlast-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
Time conversions and sampling the time graph

This section is informative.

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.

This section is informative.

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.

Hyperlinks and timing

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.

A hyperlink may be targeted at an element by specifying the value of the id 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:

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

In the above rules, the following additional constraint must also be respected:

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

This section is informative

Note that the first constraint means that a hyperlink to a child of a 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.

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 no beginEvent, endEvent or repeatEvent 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.

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:

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

The begin time of elements A and B can be immediately resolved to be at 10 and 15 seconds respectively. The begin of elements C and D are unresolved when the document starts. Therefore activating the hyperlink will resolve the begin of D but have no effect upon the presentation time for element C.

Now, assume that B is clicked at 25 seconds into the presentation. The click on B resolves the begin of C; this in turn resolves D 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 on B, D will become re-resolved to a presentation time of 65 seconds. Subsequent activation of the hyperlink while D is active will result in the seeking the presentation to 65 seconds. If the hyperlink is activated when D is no longer active, the presentation will seek to the earliest resolved begin time of D, at 30 seconds.

Implications of beginElement() and hyperlinking for seq and excl time containers

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.

This section is informative

Note that if a hyperlink targets (or if beginElement() or beginElementAt() is called for) an element A defined to begin when another element B ends, and the other element B has (e.g.) an event-base or syncbase end, the hyperlink or method call will not end element B. It will only activate element A. If the two elements are siblings within a seq or excl time container, the parent time container enforces its semantics and stops (or pauses) the running element.

If a hyperlink targets a child of an excl time container, activating the link will 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.

Propagating changes to times

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 may 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 xml:id="foo" begin="bar.end" .../>

we say that "foo" is a time-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.

Deferred elements and propagating changes to begin

This section is informative.

One exception to normal processing is made for elements that are deferred according to excl 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 element should have begun at the time it was deferred, and so it should no longer handle changed time notices.

Restart and propagating changes to times

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:

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

If the user clicks the image at 8 seconds, the image will end at 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 also Interaction with restart semantics in the section on Evaluation of begin and end time lists.

Time container duration

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: The par element, the seq element, and the excl 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, the par has a simple duration of 10 seconds. If the user activates the video at 5 seconds, the par 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>

Time container constraints on child durations

Time containers place certain overriding constraints upon the child elements. These constraints may cut short the active duration of any child element.

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 in Negative 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 xml:id="text1" begin="5s" dur="indefinite" .../>
   <audio begin="text1.end" .../>
</par>

The video will play once for 6 seconds, and then a second time but 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 the par, and the indefinite duration is cut short at the end of the simple duration of the par. 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 (the text 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 the par repeats the first time, everything 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 the priorityClass semantics, the active duration of an element may be cut short when another element in the time container begins.

The min attribute and time container constraints on child durations

This section is informative.

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 xml:id="img" min="7s" dur="4s" fill="freeze".../> 
</par> 

Time container constraints on sync-arcs and events

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.0 explicitly removes this constraint. SMIL 2.0 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.

Specifics for sync-arcs

While a sync-arc is explicitly defined relative to a particular element, if this element is not a sibling element, then the sync is resolved as a sync-relationship to 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 section Resetting element state.

Specifics for event-based timing

This section is informative

The specifics for event-based timing are discussed in the Event Sensitivity section.

Behavior of 0 duration elements

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

5.4.6 Clarifications and surprising results

This section is informative

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 xml:id="foo" begin="bar.end; activateEvent+5s".../>

See Evaluation of begin and end time lists.

5.5 Integrating SMIL Timing and Synchronization into a host language

This section is normative.

This section is informative

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.

5.5.1 Required host language definitions

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

A typical example for "presenting a document" is displaying it on a screen. Possible definitions for the document begin are that the document begins when the complete document has been received by a client over a network, or that the document begins when certain document parts have been received. A typical example of the document end is when the associated application exits or switches context to another document.

5.5.2 Required definitions and constraints on element timing

Supported events for event-base timing

5.5.3 Error handling semantics

5.6 Document object model support

This section is normative.

5.6.1 Changes for SMIL 3.0

This section is informative

In SMIL 2.1 four DOM methods for controlling the timing of elements were reserved. These methods are now defined. The definition is essentially the same as the definition in SMIL Animation [SMIL-ANIMATION].

5.6.2 Introduction

This section is informative.

Any XML-based language that integrates SMIL Timing will inherit the basic interfaces defined in DOM [DOM2] (although not all languages may require a DOM implementation). SMIL Timing specifies the interaction of timing functionality and DOM. SMIL Timing also defines constraints upon the basic DOM interfaces, and specific DOM interfaces to support SMIL Timing. The DOM Modules chapter has more information about DOM support in SMIL.

No syntax support is required to make use of the defined interfaces, although the "indefinite" argument value on the begin and end attributes may be used to describe timing that will be initiated by DOM methods. In any case, the actions of DOM timing methods are 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.

5.6.3 Events and event model

This section is informative

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.

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:

beginEvent
This event is raised when the element local timeline begins to play. It will be raised each time the element begins the active duration (i.e. when it restarts, but not when it repeats). It may be raised both in the course of normal (i.e. scheduled or interactive) timeline play, as well as in the case that the element was begun with a DOM method.
endEvent
This event is raised at the active end of the element. Note that this event is not raised at the simple end of each repeat. This event may be raised both in the course of normal (i.e. scheduled or interactive) timeline play, as well as in the case that the element was ended with a DOM method.
repeatEvent and repeat
Depending on the profile, one or the other of these events is raised when the element local timeline repeats. It will be raised each time the element repeats, after the first iteration.
repeat (n)
This event is raised when the element local timeline repeats. It will be raised each time the element repeats, after the first iteration. Associated with the repeat event is an integer that indicates which repeat iteration is beginning. The value is a 0-based integer, but the repeat event is not raised for the first iteration and so the observed values will be >= 1.

This section is informative.

If an element is restarted while it is currently playing, the element will raise an endEvent and then a beginEvent, 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 the beginEvent, endEvent, and repeat 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 the earliest time that the event could be raised (given the timing model semantics, and assuming that elements would begin and end precisely when they are defined to). There are three basic cases corresponding to begin and end conditions with zero, positive, and negative offsets respectively:

Example 1

This section is informative.

These examples assume video and audio media that are recorded to be in exact sync with one another.

<par dur="indefinite">
  <img xml:id="foo" end="click" .../>
  <video xml:id="bar" begin="foo.endEvent" .../>
  <audio xml:id="copy" 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 an endEvent 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).

Example 2

This section is informative.

<par dur="indefinite">
  <img xml:id="foo" .../>
  <video xml:id="bar" begin="foo.click+3s" .../>
  <audio xml:id="copy" begin="bar.beginEvent" .../>
</par>

The video "bar" will begin 3 seconds after the user clicks on "foo". The beginEvent 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).

Example 3

This section is informative.

<par dur="indefinite">
  <img xml:id="foo" .../>
  <video xml:id="bar" begin="foo.click-3s" .../>
  <audio xml:id="copy" 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 a beginEvent 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 the beginEvent (or endEvent) 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 the begin 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. The beginEvent will be raised when the element actually begins - in the example case when the parent time container begins. Similarly, the endEvent is 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 xml:id="foo" begin="1s; 8s" dur="3s" .../>
    </par>
  </par>
  <img xml:id="bar" begin="foo.begin" dur="1s" .../>
  <audio xml:id="beep" 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 the beginEvent or endEvent can be used. However, the author must be aware of the constraints on Event-value timing. These include the event 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 discussion Propagating changes to times.

5.6.4 Supported interfaces

This section is informative.

SMIL Timing supports several methods for controlling the behavior of animation: beginElement(), beginElementAt(), endElement(), and endElementAt(). These methods are used to begin and end the active duration of an element. Authors may (but are not required to) declare the timing to respond to the DOM using the following syntax:

<img begin="indefinite" end="indefinite" .../>

If a DOM method call is made to begin or end the element (using beginElement(), beginElementAt(), endElement() or endElementAt()), 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 in Evaluation of begin and end time lists.

The expectation of the following interface is that an instance of the ElementTimeControl interface can be obtained by using binding-specific casting methods on an instance of an animate element. A DOM application may use the hasFeature method of the DOMImplementation interface to determine whether the ElementTimeControl interface is supported or not. The feature string for this interface is "TimeControl".

Interface ElementTimeControl
IDL Definition
interface ElementTimeControl {
  void               beginElement();
  void               beginElementAt(in float offset));
  void               endElement();
  void               endElementAt(in float offset);
};

Methods
beginElement
Creates a begin instance time for the current time which is added to the list of begin instance times.
Return Value
void
No Parameters
beginElementAt
Creates a begin instance time for the current time plus or minus the passed offset which is added to the list of begin instance times.
Parameters
float offset The offset in seconds at which to begin the element.
Return Value
void
endElement
Creates an end instance time for the current time which is added to the list of end instance times.
Return Value
void
No Parameters
endElementAt
Creates an end instance time for the current time plus or minus the passed offset which is added to the list of end instance times.
Parameters
float offset The offset in seconds at which to end the element. Must be >= 0.
Return Value
void
Interface TimeEvent
The TimeEvent interface provides specific contextual information associated with Time events.
IDL Definition
interface TimeEvent : events::Event {
  readonly attribute views::AbstractView  view;
  readonly attribute long             detail;
  void               initTimeEvent(in DOMString typeArg, 
                                   in views::AbstractView viewArg, 
                                   in long detailArg);
};

Attributes
view of type views::AbstractView, readonly
The view attribute identifies the AbstractView from which the event was generated.

detail of type long, readonly
Specifies some detail information about the Event, depending on the type of event.

Methods
initTimeEvent
The initTimeEvent method is used to initialize the value of a TimeEvent created through the DocumentEvent interface. This method may only be called before the TimeEvent has been dispatched via the dispatchEvent method, though it may be called multiple times during that phase if necessary. If called multiple times, the final invocation takes precedence.
Parameters
DOMString typeArg Specifies the event type.
views::AbstractView viewArg Specifies the Event's AbstractView.
long detailArg Specifies the Event's detail.
No Return Value
No Exceptions

The different types of events that may occur are:

beginEvent
Raised when the element begins. See also Events and event model.
  • Bubbles: No
  • Cancelable: No
  • Context Info: None
endEvent
Raised when the element ends its active duration. See also Events and event model.
  • Bubbles: No
  • Cancelable: No
  • Context Info: None
repeatEvent
Raised when the element repeats. See also Events and event model.
  • Bubbles: No
  • Cancelable: No
  • Context Info: detail (current iteration)

5.6.5 IDL definition

smil.idl:

// File: smil.idl
#ifndef _SMIL_IDL_
#define _SMIL_IDL_

#include "dom.idl"

#pragma prefix "dom.w3c.org"

module smil
{
  typedef dom::DOMString DOMString;

  interface ElementTimeControl {
    void            beginElement();
    void            beginElementAt(in float offset);
    void            endElement();
    void            endElementAt(in float offset);
  };

  interface TimeEvent : events::Event {
    readonly attribute views::AbstractView  view;
    readonly attribute long             detail;
    void               initTimeEvent(in DOMString typeArg, 
                                     in views::AbstractView viewArg, 
                                     in long detailArg);
  };
};

#endif // _SMIL_IDL_

5.6.6 Java language binding

org/w3c/dom/smil/ElementTimeControl.java:

package org.w3c.dom.smil;

import org.w3c.dom.DOMException;

public interface ElementTimeControl {
    public void  beginElement();

    public void  beginElementAt(float offset);

    public void endElement();

    public void endElementAt(float offset);

}

org/w3c/dom/smil/TimeEvent.java:

package org.w3c.dom.smil;

import org.w3c.dom.events.Event;
import org.w3c.dom.views.AbstractView;

public interface TimeEvent extends Event {
    public AbstractView getView();

    public int getDetail();

    public void initTimeEvent(String typeArg, 
                              AbstractView viewArg, 
                              int detailArg);

}

5.6.7 ECMAScript language binding

Object ElementTimeControl
The ElementTimeControl object has the following methods:
beginElement()
This method returns a void.
beginElementAt(offset)
This method returns a void. The offset parameter is of type float.
endElement()
This method returns a void.
endElementAt(offset)
This method returns a void. The offset parameter is of type float.
Object TimeEvent
TimeEvent has all the properties and methods of Event as well as the properties and methods defined below.
The TimeEvent object has the following properties:
view
This property is of type AbstractView.
detail
This property is of type long.
The TimeEvent object has the following methods:
initTimeEvent(typeArg, viewArg, detailArg)
This method returns a void. The typeArg parameter is of type DOMString. The viewArg parameter is of type views::AbstractView. The detailArg parameter is of type long.

5.7 Glossary

This section is normative.

5.7.1 General concepts

This section is informative

The following concepts are the basic terms used to describe the timing model.

Synchronization relationship

A synchronization relationship is defined by the author to express that two or more elements' playback is synchronized.

Time graph

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 may "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.

Descriptive terms for times

The time model description uses a set of adjectives to describe particular concepts of timing:

implicit
This describes a time that is defined intrinsically by the element media (e.g. based upon the length of a movie), or by the time model semantics (e.g., duration of par time container).
explicit
This describes a time that has been specified by the author, using the SMIL syntax.
desired
This is a time that the author intended - it is generally the explicit time if there is one, or the implicit time if there is no explicit time.
effective
This is a time that is actually observed at document playback. It reflects both the constraints of the timing model as well as real-world issues such as media delivery.
definite
A time is definite if it is resolved to a finite, non-indefinite value.

Local time and global time

Global time is defined relative to the common reference for all elements, the document root. This is sometimes also referred to as document 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 as local time, meaning that times are relative to an element-local reference.

The following terms are used to more precisely qualify local times:

active time
Time as measured relative to the element's active duration. A time is measured as an offset from the active begin of the element.
simple time
Time as measured relative to the element's simple duration. A time is measured as an offset from the beginning of a particular instance of the simple duration.
media time
Time as measured relative to the element's media duration. A time is measured as an offset from the beginning of the media, as modified by any clipBegin or clipEnd attributes.

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, and parent 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 in Converting 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 and Non-linear media

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.

Scheduled timing

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.

document begin

The start of the interval in which the document is presented is referred to as the document begin.

document end

The end of the interval in which the document is presented is referred to as the document end.

document duration

The difference between the end and the begin is referred to as the document duration.

This section is informative

Events and interactive timing

Begin and active end times in SMIL 3.0 may 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 a mediaComplete event, and events raised by the presentation engine itself such as a pause event.

Syncbases

In scheduled timing, elements are timed relative to other elements. The syncbase for an element A is the other element B to which element A 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 arcs

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

Clocks

A Clock is a particular timeline reference that may be used for synchronization. A common example that uses real-world local time is referred to as wall-clock timing (e.g. specifying 10:30 local time). Other clocks may also be supported by a given presentation environment.

UTC: Coordinated Universal Time

Coordinated Universal Time (UTC) is the universal time scale on which time zones the world over are based. UTC is based on International Atomic Time (TAI) with leap seconds added at irregular intervals to compensate for irregularities in the Earth's rotation, so that when averaged, the Sun crosses the Greenwich meridian at noon UTC to within 0.9s. Times given in UTC 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.

Hyperlinking and timing

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

Activation

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.

Discrete and continuous Media

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 either discrete or continuous:

discrete
The media does not have intrinsic timing, or intrinsic duration. These media are sometimes described as "rendered" or "synthetic" media. This includes images, text and some vector media.
continuous
The media is naturally time-based, and generally supports intrinsic timing and an intrinsic notion of duration (although the duration may be indefinite). These media are sometimes described as "time-based" or "played" media. This includes most audio, movies, and time-based animations.

5.7.2 Timing concepts

Time containers

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.

Content/Media elements

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 3.0 functionality may use SMIL media elements and/or content described by the integrated language (e.g. paragraphs in HTML).

Basic markup

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.

Simple and active durations

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.

simple duration
This is the duration defined by the basic begin and duration markup. It does not include any of the effects of playing repeatedly, or of fill. The simple duration is defined by the explicit begin and duration, if one is specified. If the explicit times are not specified, the simple duration is defined to be the implicit duration of the element.
active duration
This is the duration during which the element plays normally. If no repeating behavior is specified, and end is not specified, the active duration is the same as the simple duration. If the element is set to play repeatedly, the simple duration is repeated for the active duration, as defined by the repeat markup.
The active duration does not include the effect of fill, except when the effect of the min attribute extends a shorter active duration. See The min and max attributes: more control over the active duration.

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 may be modified with the Descriptive Terms for Times, to further distinguish aspects of the time graph.

Hard and soft sync

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.0 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 may 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.

Pruning and cutting off an interval

The concepts of interval pruning and cutting off are distinct and should not be confused.

In some cases, after an interval has been created, it must later be pruned (deleted/removed from the timegraph) as more information becomes known and semantic constraints must be applied. When an interval is pruned, 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 the pruned 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 be cut off.

For example:

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

The "slide1" image will be cut off, but is not pruned. It is cut off because 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 is cut off, Intervals that are cut 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.

5.8 Appendix A: SMIL Timing and Synchronization modules

This section is normative.

This section defines the seventeen SMIL 3.0 Timing Modules, which include the BasicInlineTiming module and sixteen other modules that combine to provide full SMIL 3.0 timing support. The separation of the SMIL 3.0 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.

AccessKeyTiming
This module defines the attribute value syntax for the begin and end attributes that allow elements to begin and end based upon the user actuating a designated access key.
Module dependencies
None.
Included features
begin and end with access key values.
Other module specific integration requirements
The access key requested by the author may not be made available by the player (for example it may not exist on the device used, or it may be used by the user agent itself). Therefore the user agent should make the specified key available, but may map the access key to a different interaction behavior. The user agent must provide a means of identifying the access keys that may be used in a presentation. This may be accomplished in different ways by different implementations, for example through direct interaction with the application or via the user's guide.
BasicInlineTiming
This module defines the attributes that make up basic timing support for adding timing to XML elements.
Module dependencies
None.
Included features
dur with all allowed values, and begin and end attributes with simple offset values, and "indefinite".
Other module specific integration requirements
None.
BasicTimeContainers
This module defines basic time container elements, attributes that describe an element's display behavior within a time container, and end conditions for time containers.
Module dependencies
None.
Included features
par, seq elements, fill, endsync attributes.
Other module specific integration requirements
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 as fill=auto.
EventTiming
This module defines the attribute value syntax for begin and end attributes that allow elements to begin and end in response to an event.
Module dependencies
None.
Included features
begin and end with event values.
Other module specific integration requirements
None. A Host language may specify that it does not support offsets on event values.
ExclTimeContainers
This module is depreciated in SMIL 2.1.
BasicExclTimeContainers
This module is new to SMIL 2.1. It includes a time container that defines a mutually exclusive set of elements and describes the 'stop' interrupt semantic among these elements.
Module dependencies
None.
Included features
excl element, fill and endsync attributes.
Other module specific integration requirements
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 as fill="auto".
BasicPriorityClassContainers
This module is new to SMIL 2.1. It includes a child element for the excl that is used to describe interrupt semantics among group of children of the the exclusive element.
Module dependencies
The BasicExclTimeContiners module must be included in a profile containing the BasicPriorityClassContainers module
Included features
priorityClass element.
Other module specific integration requirements
None.
FillDefault
This module defines syntax for specifying default display behavior for elements.
Module dependencies
BasicTimeContainers or ExclTimeContainers or TimeContainerAttributes.
Included features
fillDefault attribute.
Other module specific integration requirements
fill=transition is only supported when BasicTransitions or InlineTransitions is included in the language profile.
MediaMarkerTiming
This module defines the attribute value syntax for the begin and end attributes that allow elements to begin and end based upon markers contained in the source content.
Module dependencies
None.
Included features
begin and end with media marker values.
Other module specific integration requirements
None.
MinMaxTiming
This module defines the attributes that allow setting minimum and maximum bounds on element active duration.
Module dependencies
None.
Included features
The max and min attributes.
Other module specific integration requirements
None.
MultiArcTiming
This module extends the attribute value syntax for the begin and end attributes to allow multiple semicolon-separated values. Any combination of the simple begin and end value types provided by the other timing modules included in the profile are allowed.
Module dependencies
At least one of: AccessKeyTiming, BasicInlineTiming, EventTiming, MediaMarkerTiming, RepeatValueTiming, SyncbaseTiming, WallclockTiming.
Included features
Any combination of the individual begin and end attribute values included in the profile, separated by semicolons.
Other module specific integration requirements
None.
RepeatTiming
This module defines the attributes that allow repeating an element for a given duration or number of iterations.
Module dependencies
None.
Included features
The repeatDur, repeatCount , and repeat attributes.
Other module specific integration requirements
repeat is deprecated and only requires inclusion in SMIL Host Language conformant profiles.
RepeatValueTiming
This module defines the attribute value syntax for begin and end attributes that allow elements to begin and end in response to repeat events with a specific Iteration value.
Module dependencies
None.
Included features
begin and end with repeat values.
Other module specific integration requirements
None.
RestartDefault
This module defines syntax for specifying default restart semantics for elements.
Module dependencies
RestartTiming.
Included features
restartDefault attribute.
Other module specific integration requirements
None.
RestartTiming
This module defines an attribute for controlling the begin behavior of an element that has previously begun.
Module dependencies
None.
Included features
restart attribute.
Other module specific integration requirements
If this module is not included, the integrating profile must define the semantics of attempting to restart and element that has already begun.
SyncBehavior
This module defines syntax for specifying the runtime synchronization behavior among elements.
Module dependencies
BasicTimeContainers or ExclTimeContainers or TimeContainerAttributes.
Included features
syncBehavior, syncTolerance attributes.
Other module specific integration requirements
None.
SyncBehaviorDefault
This module defines syntax for specifying default synchronization behavior for elements and all descendants.
Module dependencies
SyncBehavior.
Included features
syncBehaviorDefault, syncToleranceDefault attributes.
Other module specific integration requirements
None.
SyncbaseTiming
This module defines the attribute value syntax for the begin and end attributes that allow elements to begin and end relative to each other.
Module dependencies
None.
Included features
begin and end with syncbase values.
Other module specific integration requirements
None.
SyncMaster
This module defines syntax for specifying the synchronization master for a timeline.
Module dependencies
SyncBehavior.
Included features
syncMaster attribute.
Other module specific integration requirements
None.
TimeContainerAttributes
This module defines attributes for adding time container support to any XML language elements.
Module dependencies
None.
Included features
timeContainer, timeAction, fill and endsync attributes.
Other module specific integration requirements
The profile must define on what elements these attributes are legal. 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 as fill=auto.
WallclockTiming
This module the attribute value syntax for the begin and end attributes that allow elements to begin and end relative to real world clock time.
Module dependencies
None.
Included features
begin and end with wallclock times.
Other module specific integration requirements
None.
DOMTimingMethods
This module is new to SMIL 3.0. It defines the SMIL timing and synchronization DOM method calls.
Module dependencies
None.
Included features
The DOM interface ElementTimeControl with the DOM methods beginElement, beginElementAt, endElement, endElementAt; and the DOM interface TimeEvent with the attributes view and detail and the method initTimeEvent.
Other module specific integration requirements
None.

5.9 Appendix B: Annotated examples

This section is informative.

5.9.1 Example 1: Simple timing within a Parallel time container

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 a par begin by default when the par begins. For example:

<par>
   <img xml:id="i1" dur="5s"  src="img.jpg" />
   <img xml:id="i2" dur="10s" src="img2.jpg" />
   <img xml:id="i3" begin="2s" dur="5s" src="img3.jpg" />
</par>

Elements "i1" and "i2" both begin immediately when the par begins, which is the default begin time. The active duration of "i1" ends at 5 seconds into the par. The active duration of "i2" ends at 10 seconds into the par. 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 the par begins.

5.9.2 Example 2: Simple timing within a Sequence time container

Each child of a seq begins by default when the previous element ends. For example:

<seq>
   <img xml:id="i1" begin="0s" dur="5s" src="img1.jpg" />
   <img xml:id="i2" dur="10s" src="img2.jpg" />
   <img xml:id="i3" begin="1s" dur="5s" src="img3.jpg" />
</seq>

The element "i1" begins immediately, with the start of the seq, 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 the seq. Element "i2" ends 10 seconds later, at 15 seconds into the seq. 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 the seq.

5.9.3 Example 3: excl time container with child timing variants

  1. Exclusive element, children activated via link-based activation:
    <par>
        <excl>
            <par xml:id="p1"> 
            ...  
            </par>
            <par xml:id="p2">
            ...  
            </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.

  2. Exclusive element combined with event-based activation:
    <smil ...>
    ...
    <par>
        <excl>
            <par begin="btn1.activateEvent"> 
            ...  
            </par>
            <par begin="btn2.activateEvent">
            ...  
            </par>
        </excl>
        <img xml:id="btn1" src=... />
        <img xml:id="btn2" src=... />
    </par>
    ...
    <smil>

    The same jukebox example, using event-based activation.

  3. Exclusive element using scheduled timing:
    <excl>
        <ref xml:id="a" begin="0s" ... />
        <ref xml:id="b" 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.

5.9.4 Example 4: default duration of discrete media

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.

5.9.5 Example 5: end specifies end of active dur, not end of simple dur

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:

<smil ...>
...
<seq repeatCount="10" end="stopBtn.activateEvent">
   <img src="img1.jpg" dur="2s" />
   <img src="img2.jpg" dur="2s" />
   <img src="img3.jpg" dur="2s" />
</seq>
...
</smil>

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.

5.9.6 Example 6: DOM-initiated timing

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 the beginElement() method is called.

5.10 Appendix C: Differences from SMIL 1.0

This section is informative.

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.

5.11 Appendix D: Unifying event based and scheduled timing

This section is informative.

A significant motivation for SMIL 2.0 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 is activated by some interactive mechanism (often user-input events, but including local hyperlinking as well).

SMIL 3.0 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 uses Event-value specifications and the special argument value "indefinite" for the begin and end attribute values. Event values describe user interface and other events. If an element should only begin (or end) with a DOM method call, the begin and end attributes allow the special value "indefinite" to indicate this. Setting begin="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.

5.11.1 Background

SMIL 2.0 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.

5.11.2 Modeling interactive, event-based content in SMIL

To integrate interactive content into SMIL timing, the SMIL 1.0 scheduler model is extended to support several new concepts: indeterminate timing and event-activation.

With indeterminate timing, an element has an undefined begin or end time. The element still exists within the constraints of the document, but the begin or end time is determined by some external activation. 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 the beginElement() or beginElementAt() methods). From a scheduling perspective, the time is described as unresolved.

The event-activation support provides a means of associating an event with the begin or end time for an element. When the event is raised (e.g. when the user clicks on something), the associated time is resolved to a determinate time. begin or end 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 computed begin or end 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 section Handling negative offsets for begin.

Note that an event based end will not be activated until the element has already begun. Any specified end 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 the par container, it is effectively cut off by the active end of the par container.

See also the discussion of Event sensitivity.

6. SMIL 3.0 Content Control

Editor for SMIL 3.0
Dick Bulterman, CWI.
Editors for earlier versions of SMIL
Dick Bulterman, Oratrix/CWI
Jeffrey Ayars, RealNetworks
Thierry Michel, W3C.

6.1 Summary of Changes for SMIL 3.0

This section is informative.

The SMIL 3.0 specification extends the functionality SMIL 2.1 Content Control Modules [SMIL21-content-control] by introducing three new attributes: allowReorder, systemBaseProfile, and systemVersion. In addition, the new module RequiredContentControl has been defined that allows the systemRequired attribute to be specified in profiles that do not otherwise use SMIL content control. There are no new elements or other attributes provided in this version because, with the introduction of SMIL State functionality in SMIL 3.0, it is expected that new developments for managing control of content and control flow will migrate to the State-based notation. The editorial changes for SMIL 3.0 are (1) a clarification in a Normative section on expected behaviour for user agents that support dynamic evaluation and system- and/or custom-test variables, and (2) a repartitioning of the content control module structure in order to support the SMIL Tiny profile.

6.2 Introduction

This section is normative.

This section defines the SMIL 3.0 content control modules. These modules contain elements and attributes which provide for runtime content choices and optimized content delivery. SMIL content control functionality is partitioned across five modules:

Since all of the content control elements and attributes are defined in modules, designers of other markup languages may reuse this functionality on a module by module basis when they wish to include media content control in their language.

The functionality in the CustomTestAttributes module builds on the functionality of the BasicContentControl module; profiles implementing the CustomTestAttributes module must also implement the BasicContentControl and RequiredContentControl modules. The PrefetchControl and SkipContentControl modules have no prerequisites.

This section is informative.

In some of the module descriptions for content control, the concept of "user preference" may be present. User preferences are usually set by the playback engine using a preferences dialog box, but this specification does not place any restrictions on how such preferences are communicated from the user to the SMIL player.

It is implementation dependent when content control attributes are evaluated. Attributes may be evaluated multiple times. Dynamic reevaluation is allowed but not required. When dynamic reevaluation is supported by a user agent, it is expected that any system- or custom-test variable will be evaluated at the beginning of a node's execution (either at its initial begin time or each time a repeated element restarts). For situations in which more explicit control over reevaluation is required, the use of the SMIL 3.0 State modules is encouraged.

6.3 The SMIL 3.0 BasicContentControl Module

This section is normative.

6.3.1 SMIL 3.0 BasicContentControl Module Overview

SMIL 1.0 provides a "test-attribute" mechanism to process an element only when certain conditions are true, for example when the language preference specified by the user matches that of a media object. One or more test attributes may appear on media object references or timing structure elements; if the attribute evaluates to true, the containing element is played, and if the attribute evaluates to false the containing element is ignored. SMIL 1.0 also provides the switch element for expressing that a set of document parts are alternatives, and that the first one fulfilling certain conditions should be chosen. This is useful to express that different language versions of an audio file are available, and that the client may select one of them.

The SMIL 3.0 BasicContent module includes the test attribute functionality from SMIL 1.0 and extends it by supporting new system test attributes. This section will describe the use of the predefined system test attributes, the switch element and test attribute in-line placement. A mechanism for extending test attributes is presented in the CustomTestAttributes module.

Predefined System Test Attributes

This specification defines a list of test attributes that can be added to language elements, as allowed by the language designer. In SMIL 1.0, these elements are synchronization and media elements. Conceptually, these attributes represent Boolean tests. When any of the test attributes specified for an element evaluates to false, the element carrying this attribute is ignored.

SMIL 3.0 supports the full set of SMIL 2.1 system attributes. The SMIL 2.1 compatible system test attributes are:

Note that, with the exception of system-overdub-or-caption, the names of these attributes have been changed to reflect SMIL 3.0's camelCase conventions. The SMIL 1.0 hyphenated names are deprecated in this release.

SMIL 3.0 also supports system test attributes that define additional characteristics of the system environment. These are:

Finally, SMIL 3.0 supports system test attributes that define characteristics of the SMIL version (starting with version 3.0) and base profile supported by the system environment. These are:

The complete definition of each attribute is given in the attributes definition section.

The switch element

The switch element allows an author to specify a set of alternative elements from which only the first acceptable element is chosen.

This section is informative.

An example of the use of the switch is:

  ...
  <par>
    <video src="anchor.mpg" ... />
    <switch>
      <audio src="dutchHQ.aiff" systemBitrate="56000" ... />
      <audio src="dutchMQ.aiff" systemBitrate="28800" ... />
      <audio src="dutchLQ.aiff" ... />
    </switch>
  </par> 
  ...

In this example, one audio object is selected to accompany the video object. If the system bitrate is 56000 or higher, the object dutchHQ.aiff is selected. If the system bitrate is at least 28800 but less than 56000, the object dutchMQ.aiff is selected. If no other objects are selected, the alternative dutchLQ.aiff is selected, since it has no test attribute (thus is always acceptable) and no other test attributes evaluated to true.

Authors should order the alternatives from the most desirable to the least desirable. Furthermore, authors may wish to place a relatively fail-safe alternative as the last item in the switch so that at least one item within the switch is chosen (unless this is explicitly not desired). If all alternatives are equivalent an author should signal this through the allowReorder attribute on the switch, this gives the user agent the freedom to pick the best match (as opposed to the first match).

Note that some network protocols, e.g. HTTP and RTSP, support content-negotiation, which may be an alternative to using the switch element in some cases.

It is the responsibility of the SMIL user agent to determine the setting for system test attribute values. Such settings may be determined statically based on configuration settings, or they may be determined (and re-evaluated) dynamically, depending on the player implementation. When dynamic reevaluation is supported by a user agent, it is expected that any system- or custom-test variable will be evaluated at the beginning of a nodes execution (either at its initial begin time or each time a repeated element restarts). For situations in which more explicit control over reevaluation is required, the use of the SMIL 3.0 State modules is encouraged. Players may not select members of a switch at random.

System Test Attribute In-Line Use

To allow more flexibility in element selection, test attributes may also be used outside of the switch element.

This section is informative.

In the following example of in-line test attribute use, captions are shown only if the user wants captions on.

 ...
 <par>
    <audio src="audio.rm"/>
    <video src="video.rm"/>
    <textstream src="stockticker.rt"/>
    <textstream src="closed-caps.rt" systemCaptions="on"/>
 </par>
 ...

The alternatives indicated by the in-line construct could be represented as a set of switch statements, although the resulting switch could become explosive in size. Use of an in-line test mechanism significantly simplifies the specification of adaptive content, especially in those cases where many independent alternatives exist. Note, however, that there is no fail-safe alternative mechanism (such as defining an element without a test attribute inside of a switch) when using test attributes in-line.

This section is informative.

Examples of Switch and Test Attribute Use

  1. Choosing between content with different total bitrates

    In a common scenario, implementations may wish to allow for selection via a systemBitrate attribute on elements. The SMIL 3.0 player evaluates each of the elements within the switch one at a time, looking for an acceptable bitrate value.

     ...
     <par>
        <text .../>
        <switch>
           <par systemBitrate="40000">
           ...
           </par>
           <par systemBitrate="24000">
           ...
           </par> 
           <par systemBitrate="10000">
           ... 
           </par> 
        </switch> 
     </par> 
     ...

    In this example, if the system bitrate has been determined to be less than 10000 (in mobile telephone cases, for example), then none of the par constructs would be included.

  2. Choosing between audio resources with different bitrates

    The elements within the switch may be any combination of elements. For instance, one could specify an alternate audio track:

     ...
     <switch>
        <audio src="joe-audio-better-quality" systemBitrate="16000" /> 
        <audio src="joe-audio" />
     </switch>
     ... 

    If the system bitrate was less than 16000, the standard-quality audio would be presented by default.

  3. Choosing between audio resources in different languages

    In the following example, an audio resource is available both in Dutch and in English. Based on the user's preferred language, the player can choose one of these audio resources.

     ...
     <switch>
        <audio src="joe-audio-nederlands" systemLanguage="nl"/>
        <audio src="joe-audio-english" systemLanguage="en"/>
     </switch>
     ... 

    In this example, if the system language setting was anything other than Dutch or English, no audio would be presented. To make a choice the default, it should appear as the last item in the list and not contain a test attribute. In the following fragment, English is used as the default:

     ...
     <switch>
        <audio src="joe-audio-nederlands" systemLanguage="nl"/>
        <audio src="joe-audio-english" />
     </switch>
     ... 

    If the alternatives are equivalent an author may specify this through the allowReorder attribute, which gives the user agent the freedom to select the second alternative for someone who speaks both German and Dutch but prefers German:

     ...
     <switch allowReorder="yes">
        <audio src="joe-audio-nederlands" systemLanguage="nl"/>
        <audio src="joe-audio-deutsch" systemLanguage="de"/>
        <audio src="joe-audio-english" />
     </switch>
     ... 

    Note that none of these examples show the full power of language tag matching, please refer to BCP47 [BCP47] for more elaborate examples.

  4. Choosing between content written for different screens

    In the following example, the presentation contains alternative parts designed for screens with different resolutions and bit-depths. Depending on the particular characteristics of the screen, the player must use the first alternative in which all of the test attributes evaluate to true.

     ...
     <par>
        <text .../>
        <switch>
           <par systemScreenSize="1024X1280" systemScreenDepth="16">
           ...
           </par>
           <par systemScreenSize="480X640" systemScreenDepth="32">
           ...
           </par> 
           <par systemScreenSize="480X640" systemScreenDepth="16"> 
           ... 
           </par> 
        </switch> 
     </par> 
     ...
  5. Supporting multiple options via in-line use

    This example shows a video that is accompanied by zero or more media objects. If the system language has been set to either Dutch or English, then the appropriate audio object will play. In addition, if the system language has been set to either Dutch or English and systemCaptions has also been set to on, the appropriate text files will also be displayed.

      ...
      <par>
        <video src="anchor.mpg" ... />
        <audio src="dutch.aiff"   systemLanguage="nl"  ... />
        <audio src="english.aiff" systemLanguage="en" ... />
        <text  src="dutch.html"   systemLanguage="nl" systemCaption="on"... />
        <text  src="english.html" systemLanguage="en" systemCaption="on"... />
      </par> 
      ...

    If system language is set to something other than Dutch or English, no objects will be rendered (except the video). Note that there is no catch-all default mechanism when using test attributes for in-line evaluation.

  6. Choosing the language of overdub and subtitle tracks

    In the following example, a French-language movie is available with English, German, and Dutch overdub and subtitle tracks. The following SMIL segment expresses this, and switches on the alternatives that the user prefers.

     ...
     <par>
        <switch>
           <audio src="movie-aud-en.rm" systemLanguage="en"
                 systemOverdubOrSubtitle="overdub"/>
           <audio src="movie-aud-de.rm" systemLanguage="de"
                 systemOverdubOrSubtitle="overdub"/>
           <audio src="movie-aud-nl.rm" systemLanguage="nl"
                 systemOverdubOrSubtitle="overdub"/>
           <!-- French for everyone else --> 
           <audio src="movie-aud-fr.rm"/>
        </switch> 
        <video src="movie-vid.rm"/>
        <switch> 
           <textstream src="movie-sub-en.rt" systemLanguage="en" 
                 systemOverdubOrSubtitle="subtitle"/>
           <textstream src="movie-sub-de.rt" systemLanguage="de"
                 systemOverdubOrSubtitle="subtitle"/> 
           <textstream src="movie-sub-nl.rt" systemLanguage="nl"
                 systemOverdubOrSubtitle="subtitle"/> 
           <!-- French captions for those that really want them --> 
           <textstream src="movie-caps-fr.rt" systemCaptions="on"/>
        </switch> 
     </par> 
     ...

6.3.2 Elements and Attributes

SMIL 3.0 BasicContentControl defines the switch element, the allowReorder attribute and a set of predefined system test attributes.

The switch element

The switch element allows an author to specify a set of alternative elements. An element is selected as follows: the player evaluates the elements in the order in which they occur in the switch element. The first acceptable element is selected at the exclusion of all other elements within the switch. Implementations must NOT arbitrarily pick an object within a switch when test attributes for all child elements fail.

Element attributes

This element allows the allowReorder attribute, in addition to those required of all elements in the profile.

Element content

The content of the element is language implementation dependent.

In the SMIL 3.0 language profile, if the switch is used as a direct or indirect child of a body element, it may contain any media object or timing structure container, or it may contain nested switch elements. All of these elements may appear multiple times inside the switch. If the switch is used as a direct or indirect child of a head element, it may contain one or more layout elements.

The allowReorder Attribute

The allowReorder attribute signals whether a user agent may reorder the direct descendents of the switch element, based on user preferences, if it thinks this could lead to a better user experience.

The possible values are no, the default, disallowing reordering and yes, allowing reordering.

This section is informative.

User agents are free to ignore the allowReorder attribute, but if they implement prioritized language ranges as defined in BCP47 [BCP47] they are expected to use that prioritization to reorder children with systemLanguage attributes. The effect should be that the users are presented with the alternative that best matches their language preferences. Any final child without systemLanguage attribute should retain its place as the default item to present.

Authors should add the allowReorder attribute if all items in the switch are equivalent.

Predefined Test Attributes

SMIL 3.0 defines the following system test attributes. When any of the test attributes specified for an element evaluates to false, the element carrying this attribute is ignored. Note that most hyphenated test attribute names from SMIL 1.0 have been deprecated in favor of names using the current SMIL camelCase convention. For these, the deprecated SMIL 1.0 name is shown in parentheses after the preferred name.

systemAudioDesc
values: on | off
This test attribute specifies whether or not closed audio descriptions should be rendered. This is intended to provide authors with the ability to support audio descriptions in the same way that systemCaptions provides text captions. The value of systemAudioDesc is used to control object rendering in conjunction with the user's preference for receiving audio descriptions of a media object if and when these are available. A value of on indicates a preference to have such descriptions rendered when available. A value of off indicates a preference not to render such descriptions.
Authors should place systemAudioDesc = on only on elements that they wish to render when the user has indicated they want audio descriptions. Authors should place systemAudioDesc = off only on elements that they wish to render when the user has indicated they DON'T want audio descriptions.
Evaluates to true if the user preference matches this attribute value. Evaluates to false if they do not match.
systemBaseProfile
value: profile-name
Profile-name ::= "Language" | "UnifiedMobile" | "Daisy" | "Tiny" | "smilText" |User-defined-profile-name
User-defined-profile-name ::= "x-" NMTOKEN
This attribute may be used to test the base profile used by the SMIL player to execute the document. The profile name may be used to determine the presence of a set of profile-specific features. Note that since this attribute was introduced in SMIL version 3.0, only the profiles supported in that version and later may be tested with this attribute.
systemBitrate (system-bitrate)
value: the approximate bandwidth, in bits-per-second, available to the system.
The measurement of bandwidth is application specific, meaning that applications may use sophisticated measurement of end-to-end connectivity, or a simple static setting controlled by the user. In the latter case, this could for instance be used to make a choice based on the user's connection to the network. Typical values for modem users would be 14400, 28800, 56000 bit/s etc. Evaluates to true if the available system bitrate is equal to or greater than the given value. Evaluates to false if the available system bitrate is less than the given value.
The attribute can assume any integer value greater than 0. If the value exceeds an implementation-defined maximum bandwidth value, the attribute always evaluates to false.
systemCaptions (system-captions)
values: on | off
This attribute allows authors to specify a redundant text equivalent of the audio portion of the presentation. Examples of intended use are: audiences with hearing disabilities, those learning to read, or anyone who wants or needs this information.
Evaluates to true if the user preference matches this attribute value. Evaluates to false if they do not match.
systemComponent
value: an XML CDATA string containing one or more white-space separated URI's.
Each URI identifies a component of the playback system, e.g. user agent component/feature, number of audio channels, codec, HW MPEG decoder, etc. The URI is implementation dependent. Each implementation is encouraged to publish a list of component URIs which may be used to identify and resolve the presence of implementation-dependent components.
Evaluates to true if all URI's match one of the URI's that the user agent recognizes. Evaluates to false otherwise.
systemCPU
value: an XML NMTOKEN([[XML11]).
This test attribute specifies the CPU on which a user agent may be running. An implementation must allow the user the ability to set the system value to unknown for privacy.
The following list contains the suggested values for this test attribute (additional names may be supported by an implementation): alpha, arm, arm32, hppa1.1, m68k, mips, ppc, rs6000, vax, x86, unknown.

These values come from the _PR_SI_ARCHITECTURE constants defined by the mozilla project.

Evaluates to true if the user preference matches this attribute value. Evaluates to false if they do not match. The value is case-sensitive.
systemLanguage (system-language)
values: a comma-separated list of language tags as defined in BCP47 [BCP47], or an empty/null string
Each of the language tags is matched against the users' language preferences according to the BCP47 Basic Filtering matching algorithm [BCP47]. If any language tag matches the test attribute evaluates to true, else it evaluates to false.
If a null or empty string is specified, the test attribute evaluates to false.

The syntax of the systemLanguage and the deprecated system-language attributes are defined using EBNF notation (as defined in [XML11]) as list of XML namespace prefixes [XML-NS], separated by the ',' character:

SystemLanguageArgumentValue ::= (LanguageTag (S? "," S? LanguageTag)*)?
      

Where allowed white space is indicated as 'S', defined as follows (taken from the [XML11] definition for 'S'):

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

This section is informative.

BCP47: This is actually an active document that can, over time, refer to newer RFCs as technology progresses. As of this writing BCP47 consists of RFC4646 for defining language tags and RFC4647 for defining the matching algorithm.

Implementation: When making the choice of linguistic preference available to the user, implementers should take into account the fact that most users are not familiar with the details of RFC4647 language matching, and should provide appropriate guidance. As an example, users may mistakenly assume that on selecting "en-gb", they will be served any kind of English document if British English is not available. The user interface for setting user preferences should guide the user to add "en" to get the best matching behavior.

systemOperatingSystem
value: an XML NMTOKEN ([XML11])
This test attribute specifies the operating system on which a user agent may be running. An implementation must allow the user the ability to set the user preference to unknown for privacy.
The following list contains the suggested values for this test attribute (additional names may be supported by an implementation): aix, beos, bsdi, dgux, freebsd, hpux, irix, linux, macos, ncr, nec, netbsd, nextstep, nto, openbsd, openvms, os2, osf, palmos, qnx, sinix, rhapsody, sco, solaris, sonly, sunos, unixware, win16, win32, win9x, winnt, wince, unknown.

This section is informative.

These values come from the _PR_SI_SYSNAME constants defined by the mozilla project.

Evaluates to true if the user preference matches this attribute value. Evaluates to false if they do not match. The value is case-sensitive.
systemOverdubOrSubtitle
values: overdub | subtitle
This attribute specifies whether subtitles or overdub is rendered. overdub selects for substitution of one voice track for another, and subtitle means that the user prefers the display of text in a language other than that which is being used in the audio track.
Evaluates to true if the user preference matches this attribute value. Evaluates to false if they do not match.
system-overdub-or-caption
values: caption | overdub
This test attribute has been deprecated in favor of using systemOverdubOrSubtitle and systemCaptions.
This attribute is a setting which determines if users prefer overdubbing or captioning when the option is available.
Evaluates to true if the user preference matches this attribute value. Evaluates to false if they do not match.
systemScreenDepth (system-screen-depth)
values: a number greater than 0
This attribute specifies the depth of the screen color palette in bits required for displaying the element. Typical values are 1 | 4 | 8 | 24 | 32.
Evaluates to true if the playback engine is capable of displaying images or video with the given color depth. Evaluates to false if the playback engine is only capable of displaying images or video with a smaller color depth.
systemScreenSize (system-screen-size)
value: Screen-size
Attribute values have the following syntax:
Screen-size ::= Screen-height S? "X" S? Screen-width
Each of these is a pixel value, and must be an integer value greater than 0.
Evaluates to true if the playback engine is capable of displaying a presentation of the given size. Evaluates to false if the playback engine is only capable of displaying smaller presentations.
systemVersion
value: 3.0 .
This attribute may be used to test the version number of the SMIL player executing the document. The number may be used to determine the presence of a set of specification-specific features. Since this attribute was introduced in SMIL version 3.0, only values of 3.0 and later may be tested with this attribute.

It is the responsibility of the SMIL 3.0 Player to determine the settings for each predefined test variable. These values may be determined by static configuration settings, or they may be evaluated dynamically during runtime. Such setting and (re)evaluation behavior is implementation dependent. When dynamic reevaluation is supported by a user agent, it is expected that any system- or custom-test variable will be evaluated at the beginning of a nodes execution (either at its initial begin time or each time a repeated element restarts). For situations in which more explicit control over reevaluation is required, the use of the SMIL 3.0 State modules is encouraged.

For this version of SMIL elements with specified test attributes that evaluate to false, or elements within a switch that are not selected, are considered to be ignored and will behave as though they were not specified in the document. Any references to these elements will be as if the elements were not in the document. In particular, any ID references to the element will act as if there was no element with that ID. Languages that integrate this module must specify any additional behavior related to these ignored elements. In the SMIL 3.0 Language profile, timing attributes that reference invalid IDs are treated as being indefinite.

This section is informative.

Authors should be aware that this model for handling ignored elements may be revised in a future version of SMIL, and the related semantics may well change. These changes should not affect implementations that only support parse-time (or equivalent) evaluation of test attributes and/or the switch element. However, the semantics of dynamic re-evaluation (i.e. re-evaluation during document presentation) of test attributes and/or switch elements are not defined in this version of SMIL; this will be addressed in a future version.

Authors should realize that if several alternative elements are enclosed in a switch, and none of them evaluate to true, this may lead to situations such as a media object being shown without one or more companion objects. It is thus recommended to include a "catch-all" choice at the end of a switch which is acceptable in all cases.

6.3.3 Integration Requirements for the BasicContentControl Module

The functionality in this module does not build on functionality defined in other SMIL 3.0 modules.

6.3.4 Document Type Definition (DTD) for the BasicContentControl Module

See the full DTD for the SMIL Content Control modules.

6.4 The SMIL 3.0 CustomTestAttributes Module

This section is normative.

6.4.1 SMIL 3.0 CustomTestAttributes Module Overview

The use of predefined system test attributes in the SMIL BasicContentControl module provides a selection mechanism based on attributes that are fixed within the module's definition. The CustomTestAttribute module extends this facility with the definition of author-defined custom test attributes. Custom test attributes allow presentation authors to define their own test attributes for use in a specific document. Custom test attributes may be shared among application documents using the uid attribute.

As with system test attributes, custom test attributes may be used within timing structure and media object elements; if they evaluate to true, the containing element is activated and if they evaluate to false, the containing element is ignored. In this version of SMIL, an ignored element will be treated as if it were not part of the source document. As a result, any element referencing the ID of the ignored node will, in effect, reference an invalid ID. Languages that integrate this module must specify any additional behavior related to these ignored elements.

Since custom test attributes are application/document specific, they need a mechanism to allow attribute definition and attribute setting. Attribute definition is done via the customAttributes and customTest elements. The initial state of any custom test attribute may be set at author-time with the defaultState attribute, which takes a value of either true or false. This module provides an override attribute with a value hidden that gives an author the ability to discourage runtime resetting of any attributes using these mechanisms.

The state of the attribute can be changed in one of three ways:

  1. by modifying the value of the default state attribute in the document source before delivery to the player;
  2. by using the unique identifier given in the uid attribute to dereference a runtime value for the customTest; or
  3. by an interface presented to the user (or the user agent) through the document player at runtime.

The exact rules for setting and modifying the values associated with custom test attributes are given below.

An implementation may support either, both, or none of methods 2 and 3. If method 2 is supported, the URI value in uid is simply a unique identifier and does not imply that the runtime value must be fetched over the Web. The value may be stored and retrieved locally, and simply identified by the uid. The precise manner in which this is done is implementation dependent. If method 3 is supported, the custom test attribute facility does not require any specific UI support for direct user manipulation of the custom test attributes.

This section is informative.

Example Use

The following example shows one way in which custom test attributes may be applied within a SMIL 3.0 Language profile document:

<smil>
  <head>
    <layout>
       <!-- define projection regions -->
    </layout>
    <customAttributes>
      <customTest xml:id="west-coast" title="West Coast Edition" 
        defaultState="false" override="visible"  
        uid="http://defs.example.org/user-settings/west-coast" />
      <customTest xml:id="east-coast" title="East Coast Edition" 
        defaultState="false" override="visible" 
        uid="http://defs.example.org/user-settings/east-coast" />
      <customTest xml:id="far-north"  title="Northern Edition"
        defaultState="false" override="visible"
        uid="http://defs.example.org/user-settings/far-north" />
      <customTest xml:id="the-rest"   title="National Edition"
        defaultState="true"  override="hidden" />
    </customAttributes>
  </head>
  <body>
    ...
    <par>
      <img src="background.png" region="a"/>
      <video src="story_1v.rm" region="b" />
      <switch>
        <audio src="story_1w.rm" region="c" customTest="west-coast"/>
        <audio src="story_1e.rm" region="c" customTest="east-coast"/>
        <audio src="story_1n.rm" region="c" customTest="far-north"/>
        <audio src="story_1r.rm" region="c" customTest="the-rest"/>
      </switch>
    </par>
    ...
  </body>
</smil>

The customAttributes element in the header contains the definition of the available custom test attributes. Each custom test attribute, defined by the customTest element, contains an identifier and a title (which may be used by a user agent, if available, to label the attribute), as well as an (optional) initial state definition, a UID that contains a unique identifier for the value setting for this attribute and an override flag.

The custom test variables named "west-coast", "east-coast" and "far-north" are defined with a default rendering state of false. They each contain a reference to a URI which is used to define local settings for the respective variables.

The custom test variable "the-rest" is defined with a default rendering setting of true.

Inside the body, a SMIL switch construct is used to select media objects for inclusion in a presentation depending on the values of the various custom test attributes. The first object that contains a value of true will be rendered, and since in this example the last option will always resolve true, it will be rendered if no other objects resolve to true.

While this example shows switch-based use of custom test attributes, the facility could also be applied as test attributes in in-line use.

Rules for Setting Values

The setting of the value associated with a custom test attribute proceeds as follows:

  1. The initial setting is taken from the value of the defaultState attribute, if present. If no default state is explicitly defined, a value of false is used.
  2. Next, if a URI mechanism is supported by the implementation, the URI defined by the uid attribute is checked to see if a persistent value has been defined for the custom test attribute with the associated id. If such a value is present, it is used instead of the default state defined in the document (if any). Otherwise, the existing initial state is maintained.
  3. Next, if a UI-based mechanism (either via the SMIL DOM, a player GUI or some other means) is available and a value has been set by the user, the value associated with the custom test attribute is set to the user-specified value. If no user preference has been defined, either the UID-based value or the default value from the document text (in that order) is used.

Note that a user setting of the custom test attribute will take precedence over a URI setting. If the user has not specified a value for the attribute then the URI setting takes precedence. As with predefined system test attributes, this evaluation will occur in an implementation-defined manner. The value may be (re)evaluated dynamically, but this is not required. When dynamic reevaluation is supported by a user agent, it is expected that any system- or custom-test variable will be evaluated at the beginning of a nodes execution (either at its initial begin time or each time a repeated element restarts). For situations in which more explicit control over reevaluation is required, the use of the SMIL 3.0 State modules is encouraged. Note also that not all implementations need support uid or UI setting of attributes.

6.4.2 Elements and Attributes

This section defines the elements and attributes that make up the functionality in the SMIL CustomTestAttributes module. The customAttributes and customTest elements are used to define custom test attribute variables and the customTest attribute is used in-line on media object and timing structure references to control evaluation of the containing elements.

The customAttributes element

The customAttributes element contains definitions of each of the custom test attributes. The contained elements define a collection of author-specified test attributes that may be used in switch statements or as in-line test attributes in the document.

Element attributes

This element does not have attributes beyond those required of all elements in the profile.

Element content

The customAttributes element may contain one or more customTest elements.

The customTest element

The customTest element defines an author-specified name that will be used as the test argument in the switch element or in-line on media object and timing structure elements. The customTest elements are defined within the section delineated by the customAttributes elements that make up part of the document header.

Element attributes
defaultState
values: true | false
The initial state for the named custom test variable is given in the value of this attribute. If unspecified, it defaults to false.
The run-time state for the named custom test variable may be set according to the rules for uid and/or override attribute processing, if present. The values are not case-sensitive.
override
values: visible | hidden
This attribute allows the author to choose whether the ability to override the initial state of a custom test variable should be presented to the typical user, or whether that choice should be reserved for users that specifically express a preference for this access. If the value of the override attribute is visible, then the user agent should make available to the user a means to set the custom test variable value in its default configuration either directly, via the SMIL DOM, or by some other mechanism. If the value of the override attribute is hidden, then the user agent should not present to the user a means to set the custom attribute value unless the user has expressed a preference for this access. The values are not case-sensitive. The default value is hidden.
uid
values: A URI
The URI identifies the associated custom test for persistent use. The user agent should use this as the key to store and retrieve values associated with the custom test attribute, and take care that privacy and security issues are regarded. If permitted by the override attribute, a resolved reference to a setting via the uid attribute defines the initial setting of the custom test value; this value may be overridden by the user/user-agent if permitted by the override attribute. It is up to the runtime environment to enforce this attribute.

This section is informative.

The actual evaluation mechanism associated with the URI is implementation dependent. It may vary from a simple lookup in a local file or registry, to a secure reference via a capabilities database, and may be influenced by other configuration settings provided by the implementation.

Element content

None.

The customTest attribute

In addition to the customAttributes and customTest elements, this module provides a customTest attribute that can be applied by language designers to media objects and timing structure elements requiring selection. In all operational aspects, the custom test attribute is similar to the predefined system test attribute facility of the BasicContentControl module.

customTest
value: a list of XML identifiers
The identifiers, defined in the customTest elements, define variables that are evaluated as test attributes. If the variables all evaluate to true, the associated element is evaluated, otherwise it and its content are skipped. customTest attributes whose values don't match the identifier of a customTest element evaluate to false

The syntax of the customTest is defined using EBNF notation (as defined in [XML11]) as list of  customTest element identifier references, separated by the '+' character:

CustomTestArgumentValue ::= Idref (S? "+" S? Idref)*
Idref ::= Name

Where allowed white space is indicated as 'S', defined as follows (taken from the [XML11] definition for 'S'):

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

and Idref is a Name as defined in [XML11] is a reference to a customTest element.

6.4.3 Integration Requirements for the CustomTestAttribute Module

The functionality in this module builds on functionality defined in the BasicContentControl module, which is a required prerequisite for inclusion of the CustomTestAttribute module.

The profile implementing the custom test elements and attributes must provide a means of associating a unique XML identifier with a customTest element, so that it can be used by the customTest attribute. And the profile should provide a means of associating descriptive text with a customTest element, which may be used in a GUI or other selection mechanism that may be presented to the user. For the SMIL 3.0 Language Profile, the element's id and title attributes serve this purpose.

6.4.4 Document Type Definition (DTD) for the CustomTestAttribute Module

See the full DTD for the SMIL Content Control modules.

6.5 The SMIL 3.0 PrefetchControl Module

This section is normative.

6.5.1 SMIL 3.0 PrefetchControl Module Overview

This module defines an element and attributes that may be used to control the fetching of content from a server in a manner that will improve the rendering performance of the document.

This element will give a suggestion or hint to a user agent that a media resource will be used in the future and the author would like part or all of the resource fetched ahead of time to make the document playback smoother. User-agents may ignore prefetch elements, though doing so may cause an interruption in the document playback when the resource is needed. It gives authoring tools or savvy authors the ability to schedule retrieval of resources when they think that there is available bandwidth or time to do it. A prefetch element is contained within the body of an XML document, and its scheduling is based on its lexical order unless explicit timing is present.

This section is informative.

Prefetching data from a URL that changes the content dynamically is potentially dangerous: if the entire resource isn't prefetched, a subsequent request for the remaining data may yield data from a newer resource. A user agent should respect any appropriate caching directives applied to the content, e.g. no-cache 822 headers in HTTP. More specifically, content marked as non-cacheable would have to be refetched each time it was played, where content that is cacheable could be prefetched once, with the results of the prefetch cached for future use.

Examples

  1. Prefetch an image so it can be displayed immediately after a video ends:
     <smil xmlns="http://www.w3.org/ns/SMIL" version="3.0" baseProfile="Language"> 
       <body> 
         <seq>
           <par>
             <prefetch xml:id="endimage"
                src="http://www.example.org/logo.gif"/>
             <text xml:id="interlude"
                src="http://www.example.org/pleasewait.html" fill="freeze"/>
           </par>
           <video xml:id="main-event" src="rtsp://www.example.org/video.mpg"/> 
           <img src="http://www.example.org/logo.gif" dur="5s"/>  
        </seq> 
       </body> 
     </smil> 

    The example starts with a prefetch in parallel with the rendering of a text object. The text is discrete media so it ends immediately, the prefetch is defaulted to prefetch the entire image at full available bandwidth and the prefetch element ends when the image is downloaded. That ends the <par> and the video begins playing. When the video ends the image is shown.

  2. Prefetch the images for a button so that rollover occurs quickly for the end user:
     <html>
     <body>
         <prefetch xml:id="upimage" src="http://www.example.org/up.gif"/>
         <prefetch xml:id="downimage" src="http://www.example.org/down.gif"/>
         ....
         <!-- script will change the graphic on rollover -->
         <img src="http://www.example.org/up.gif"/>
       </body>
     </html>
        

6.5.2 Elements and Attributes

The prefetch element

The prefetch gives authors a mechanism to influence the scheduling of media object transfers from a server to the player.

Documents must still playback even when the prefetch elements are ignored, although rebuffering or pauses in presentation of the document may occur. If the prefetch for a prefetch element is ignored, any timing on the element is still respected, e.g. if a prefetch element has a dur="5s", elements that depend on the prefetch element's timing behave as if the prefetch took 5 seconds.

The intrinsic duration of a prefetch element is either the duration of the media fetch, if the prefetch operation is supported by the implementation, or zero if prefetch is not supported.

If a prefetch element is repeated, due to restart or repeat on a parent element the prefetch operation should occur again. This insures appropriately "fresh" data is displayed if, for example, the prefetch is for a banner ad to a URL whose content changes with each request.

Element attributes

The prefetch element supports the following attributes:

mediaSize
values: Bytes-value | Percent-value
Defines how much of the resource to fetch as a function of the file size of the resource. To fetch the entire resource without knowing its size, specify 100%. The default is 100%.
mediaTime
values: Clock-value | Percent-value
Defines how much of the resource to fetch as a function of the duration of the resource. To fetch the entire resource without knowing its duration, specify 100%. The default is 100%.
For discrete media (non-time based media like text/html or image/png) using this attribute causes the entire resource to be fetched.
bandwidth
values: Bitrate-value | Percent-value
Defines how much network bandwidth the user agent should use when doing the prefetch. To use all that is available, specify 100%. The default is 100%.

Any attribute with a value of "0%" is ignored and treated as if the attribute wasn't specified.

If both mediaSize and mediaTime are specified, mediaSize is used and mediaTime is ignored.

If the clipBegin or clipEnd in the media object are different from the prefetch, an implementation can use any data that was fetched but the result may not be optimal.

Attribute value syntax
Bytes-value
The Bytes-value value has the following syntax:

Bytes-value ::= DIGIT+ /* any positive number */

Percent-value
The percent-val value has the following syntax:

Percent-value ::= DIGIT+ "%" /* any positive number in the range 0 to 100 */

Clock-value
The Clock-value value has the following syntax:
Clock-value       ::= ( Hms-val | Smpte-val )
Smpte-val         ::= ( Smpte-type )? Hours ":" Minutes ":" Seconds 
                      ( ":" Frames ( "." Subframes )? )?
Smpte-type        ::= "smpte" | "smpte-30-drop" | "smpte-25"
Hms-val           ::= ( "npt=" )? (Full-clock-val | Partial-clock-val 
                      | Timecount-val)
Full-clock-val    ::= Hours ":" Minutes ":" Seconds ("." Fraction)?
Partial-clock-val ::= Minutes ":" Seconds ("." Fraction)?
Timecount-val     ::= Timecount ("." Fraction)? (Metric)?
Metric            ::= "h" | "min" | "s" | "ms"
Hours             ::= DIGIT+ /* any positive number */
Minutes           ::= 2DIGIT /* range from 00 to 59 */
Seconds           ::= 2DIGIT /* range from 00 to 59 */
Frames            ::= 2DIGIT /* smpte range = 00-29, smpte-30-drop range = 00-29, smpte-25 range = 00-24 */
Subframes         ::= 2DIGIT /* smpte range = 00-01, smpte-30-drop range = 00-01, smpte-25 range = 00-01 */
Fraction          ::= DIGIT+
Timecount         ::= DIGIT+
2DIGIT            ::= DIGIT DIGIT
DIGIT             ::= [0-9]

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

This note is informative

A value of three sets of colon-separated digits can be produced both by Hms-val and Smpte-val. This is however not aproblem since in both cases the values are interpreted as Hours, Minutes and Seconds.

Bitrate-value
The Bitrate-value value specifies a number of bits per second. It has the following syntax:

Bitrate-value ::= DIGIT+ /* any positive number */

6.5.3 Integration Requirements for the PrefetchControl Module

A profile integrating the PrefetchControl module must add the attributes necessary to specify the media to be fetched. In general, these will be the same resource specifying attributes as those on the media elements themselves. In addition, the profile must add any necessary attributes to control the timing of the prefetch element.

6.5.4 Document Type Definition (DTD) for the PrefetchControl Module

See the full DTD for the SMIL Content Control modules.

6.6 The SMIL 3.0 SkipContentControl Module

This section is normative.

6.6.1 SMIL 3.0 SkipContentControl Module Overview

This module contains one attribute, skip-content attribute, that can be used to selectively control the evaluation of the element on which this attribute appears. This attribute is introduced for future extensibility of SMIL. The functionality is unchanged from SMIL 1.0.

6.6.2 Elements and Attributes

Element definition

The SkipContentControl module does not contain any element definitions.

The skip-content attribute

skip-content
value: true | false
This attribute controls whether the content of an element is evaluated or should be skipped.
  • If a new element is introduced in a future version of language allowing markup from a previous version of the language as element content, the skip-content attribute controls whether this content is processed by the user agent.
  • If an empty element in a version of a language becomes non-empty in a future SMIL version, the skip-content attribute controls whether this content is ignored by a user agent, or results in a syntax error.
If the value of the skip-content attribute is true, and one of the cases above apply, the content of the element is ignored. If the value is false, the content of the element is processed.
The default value for skip-content is true.

6.6.3 Integration Requirements for the SkipContentControl Module

It is the responsibility of the language profile to specify which elements have skip-content attributes to enable this expansion mechanism.

6.7 The SMIL 3.0 RequiredContentControl Module

This section is normative.

6.7.1 SMIL 3.0 RequiredContentControl Module Overview

This module contains one attribute, systemRequired, which is used to identify one or more namespace prefixes. These prefixes may be used to define a minimum set of modules that a user agent must support to process a given SMIL file. This attribute is a critical component of the SMIL Scalability Framework.

6.7.2 Elements and Attributes

Element definition

The RequiredContentControl module does not contain any element definitions.

The systemRequired attribute

systemRequired (system-required)
value: list of namespace prefix language extensions
This attributes provides an extension mechanism for new elements or attributes. Evaluates to true if all of the extensions in the list are supported by the implementation, otherwise, this evaluates to false. The syntax of the systemRequired and the deprecated system-required attributes are defined using EBNF notation (as defined in [XML11]) as list of XML namespace prefixes [XML-NS], separated by the '+' character:
SystemRequiredArgumentValue := Nmtoken (S? "+" S? Nmtoken)*

Where allowed white space is indicated as 'S', defined as follows (taken from the [XML11] definition for 'S'):

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

6.7.3 Integration Requirements for the RequiredContentControl Module

It is the responsibility of the language profile to specify which elements support the systemRequired attribute. In order to support the SMIL Scalability Framework, all profiles are expect to at least support this attribute on the top-level SMIL element.

7. SMIL 3.0 Layout

Editor for SMIL 3.0
Dick Bulterman, CWI
Editors for Earlier Versions of SMIL
Aaron Cohen, Intel
Dick Bulterman, Oratrix/CWI
Erik Hodge, RealNetworks.

7.1 Summary of Changes for SMIL 3.0

This section is informative.

In order to provide better support for multiple layout processors and to meet the needs of the new SMIL 3.0 Tiny profile, SMIL 3.0 Layout defines the StructureLayout module. This module defines the layout element, which can now be used to identify the layout mechanism used by a SMIL profile independently of the SMIL basic layout architecture.

SMIL 3.0 Layout also extends the BasicLayout module with the backgroundOpacity attribute, which specifies the background opacity of a region. This attribute applies to both the background color of a SMIL layout region and to the opacity of background images specified for a region (if supported by the profile). This attribute complements new features defined in the Media Objects module to control media opacity for media types that support opacity control.

SMIL 3.0 Layout now restricts the functionality in the OverrideLayout module to be dependent on the ability to define dynamic subregions on media objects in the SubRegionLayout module. This removes a functional conflict with overriding behavior on base region values when subregion positioning is not supported.

SMIL 3.0 changes the value of the soundLevel attribute to now contain a relative sound level definition. This provides a logarithmic/exponential volume control mechanism for audio.

This version of the SMIL 3.0 Layout modules also provides minor editorial changes to the text of all of the module descriptions and it provides an expanded set of informative examples of layout element and attribute use.

7.2 Introduction

This section is normative.

This section defines the SMIL Layout Modules, which contain elements and attributes that allow positioning of media elements on visual and audio rendering surfaces and to control of audio volume. Since these elements and attributes are defined in modules, designers of other markup languages can choose the appropriate level of functionality to be included in their languages. Language designers incorporating other SMIL modules may include all, some or none of the modules described in this section.

7.2.1 Module Overview

SMIL 3.0 Layout functionality is partitioned across the following eight modules:

StructureLayout
The StructureLayout module defines the top-most layout element and its attribute. This element identifies the layout mechanism used in a SMIL presentation (if any). All other layout modules are dependent on this functionality.
BasicLayout
The BasicLayout module extends the StructureLayout module and defines the core SMIL layout elements and their attributes. Using these attributes, basic positioning may be achieved for simple presentations.
AudioLayout
The AudioLayout module extends the BasicLayout module with a single attribute to control audio output sound levels.
MultiWindowLayout
The MultiWindowLayout module extends the BasicLayout module by defining an alternative to the root-layout element for defining the outer containing rendering space for a presentation. This module also defines functionality for supporting multiple top-level windows simultaneously.
SubRegionLayout
The SubRegionLayout module extends the BasicLayout module by defining a facility for creating logically nested regions. These regions may be created statically within the layout element or dynamically on a media object reference.
AlignmentLayout
The AlignmentLayout module extends the BasicLayout module by defining attributes to position content within a region based on a set of registration points and alignment algorithms. Several convenience attribute values are also provided to simply common authoring cases.
BackgroundTilingLayout
The BackgroundTilingLayout module extends the BasicLayout module by defining a facility to fill a region background with a tiled image instead of simply a background color.
OverrideLayout
The OverrideLayout module extends the SubRegionLayout module by allowing per-media-object overrides of various layout attribute values.

This section is informative.

Note that the SMIL 2.0 HierarchicalLayout module was deprecated in SMIL 2.1; all of this module's functionality was partitioned across other layout modules and thus it is not part of SMIL 3.0 Layout.

7.2.2 Support for Multiple Layout Models

The SMIL layout architecture allows support for multiple layout models within a presentation. Media layout may be described using the SMIL layout syntax described in this chapter or by using another layout mechanism, such as CSS2 syntax [CSS2]. Other layout types are possible as well.

Support for multiple layout models is implementation profile dependent. A given profile may support multiple layout models simultaneously (with selection performed using the SMIL switch element), or it may dictate that only a single layout model is supported (such as the use of CSS2 layout within the XHTML+SMIL candidate profile[XHTMLplusSMIL].

The remainder of this chapter defines the mechanism to identify the layout model used by a presentation and then describes the features of the SMIL 3.0 smil-basic layout semantics.

7.3 The SMIL StructureLayout Module

This section is normative.

7.3.1 Overview

The SMIL StructureLayout module defines the layout element, which is used to indicate the layout model to be used with a given SMIL document. The layout element is used in the document head section.

7.3.2 Elements and Attributes

This section defines the elements and attributes that make up the functionality in the SMIL StructureLayout module.

The layout element

The layout element contains the elements that define a particular layout model to be used within a SMIL presentation. If present, the layout element must appear in the head section of the document.

If a document contains no layout element, no SMIL-defined default values are assigned and the positioning of the body elements is totally implementation-dependent.

SMIL-defined default layout semantics can be assigned to all renderable elements by selecting the empty layout element <layout></layout>.

Element Attributes
type
This attribute specifies which layout language is used in the layout element. If the user agent does not understand this language, it must skip the element and all of its content up until the next </layout> tag. The default value of the type attribute is "text/smil-basic-layout". This identifier value supports SMIL 3.0 BasicLayout module layout semantics.
Element content

If the type attribute of the layout element has the value "text/smil-basic-layout", (or if no type attribute is defined) the layout element may contain the elements of the BasicLayout module, plus any additional layout modules defined by the profile incorporating these modules. Profiles incorporating the BasicLayout module may define additional elements that are allowed as children of the layout element.

If the type attribute of the layout element has a value other than "text/smil-basic-layout", the element contains character data.

7.3.3 StructureLayout Module Events

This module does not define any SMIL events.

7.3.4 SMIL StructureLayout Implementation and Integration

Implementation Details

This module provides a wrapper for a particular layout model. A given SMIL rendering agent may support all, some or none of the layout models defined for use with SMIL 3.0.

Integration Requirements

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

7.3.5 Document Type Definition (DTD) for the StructureLayout Module

See the full DTD for the SMIL Layout modules.

7.4 The SMIL BasicLayout Module

This section is normative.

7.4.1 Overview

SMIL BasicLayout module defines a layout model for organizing media elements into regions on the visual rendering surface. The regions are declared within the layout element in the document head. Media elements declare which region they are to be rendered into with the region attribute.

Each region has a set of CSS2 compatible properties such as top, left, height, width, and backgroundColor. These properties may be declared using a syntax defined by the type attribute of the layout element. In this way, media layout can be described using the either SMIL basic layout syntax or CSS2 [[CSS2 - absolute-positioning]] syntax (note that these are not functionally identical). Other layout types are possible as well.

This section is informative.

An example declaration to define a region with the id "r" at location 15,20 that is 100 pixels wide by 50 pixels tall using the SMIL BasicLayout module is:

    <layout>
      <region xml:id="r" top="15px" left="20px" width="100px" height="50px"/>
    </layout>

To display a media element in the region declared above, specify the region's id as the region attribute of the media element:

    <ref region="r" src="http://..." />

7.4.2 Elements and Attributes

This section defines the elements and attributes that make up the functionality in the SMIL BasicLayout module.

The region element

The region element controls the position, size and scaling of media object elements that are placed within its rendering space.

The position of a region, as specified by its top, bottom, left, and right attributes, is always relative to the parent geometry, which is defined by the parent element. For the SMIL BasicLayout module, all region elements must have as their immediate parent a layout element, and the region position is defined relative to the root window declared in the sibling root-layout element. The root-layout element is considered to be the logical parent of all region elements in SMIL BasicLayout. The intrinsic size of a region is equal to the size of the logical parent's geometry.

When region sizes, as specified by width and height attributes are declared relative with the "%" notation, the size of a region is relative to the size of the parent geometry. Sizes declared as absolute pixel values maintain those absolute values.

Conflicts between the region size and position attributes width, height, bottom, left, right, and top are resolved according to the rules for placeholder elements as detailed below. The default values of region position and size attributes is specified as auto. This attribute value has the same meaning here that it does in [CSS2], when there is no distinction drawn between replaced and non-replaced element.

A placeholder element is one which has no intrinsic width or height, but does have a bounding-box which has a width and height. SMIL BasicLayout regions are placeholder elements. Placeholder elements are clipped to the bounding box.

The governing equation for the horizontal dimension is:

bbw (bounding-box-width) = left + width + right

Given that each of these three parameters may have either a value of "auto" or a defined value not "auto", then there are 8 possibilities:

Attribute values

Result before clipping to the bounding box

left width right left width right
auto auto auto 0 bbw 0
auto auto defined 0 bbw - right right
auto defined auto 0 width bbw - width
auto defined defined bbw - right - width width right
defined auto auto left bbw - left 0
defined auto defined left bbw - right - left right
defined defined auto left width bbw - left - width
defined defined defined left width bbw - left - width

The vertical attributes height, bottom, and top are resolved similarly. The governing equation for the vertical dimension is:

bbh (bounding-box-height) = top + height + bottom

Given that each of these three parameters may have either a value of "auto" or a defined value not "auto", then there are 8 possibilities:

Attribute values

Result before clipping to the bounding box

top height bottom top height bottom
auto auto auto 0 bbh 0
auto auto defined 0 bbh - bottom bottom
auto defined auto 0 height bbh - height
auto defined defined bbh - bottom - height height bottom
defined auto auto top bbh - top 0
defined auto defined top bbh - bottom - top bottom
defined defined auto top height bbh - top - height
defined defined defined top height bbh - top - height
Element attributes

The region element may have the following visual attributes:

backgroundColor
The use and definition of this attribute are identical to the "background-color" property in the CSS2 specification. Unlike SMIL 1.0, this module requires support for CSS2 system colors [CSS2], (Section 18.2).
This attribute specifies the background color used to fill the area of a region displaying media that is not filled by the media. The display of the background color when the region is not in use by a media element is controlled by the showBackground attribute.
The backgroundColor attribute may take on the CSS value inherit. This means that the background color will be that of the parent element. If the parent element does not have an applicable background color property, the default value depends on the language profile: if the background-color attribute is supported by the language profile, the default value of backgroundColor is inherited from background-color. Otherwise, the default value is transparent. The interaction of this attribute with backgroundOpacity is discussed in the Implementation section.
background-color
Deprecated. Equivalent to backgroundColor, which replaces this attribute. The language profile must define whether or not the background-color attribute is supported. The default value of the background-color attribute is transparent.
backgroundOpacity
This attribute defines the opacity of the background of the region. It accepts a percentage value in the range 0-100% or a number in the range 0.0-1.0, with 100% or 1.0 meaning fully opaque. If an implementation cannot support manipulation of the background opacity value, this attribute is ignored. The default value of this attribute is 100%. The interaction of this attribute with backgroundColor is discussed in the Implementation section.
bottom
The use and definition of this attribute are identical to the "bottom" property in the CSS2 specification. Attribute values can be non-negative "percentage" values, and a variation of the "length" values defined in CSS2. For "length" values, SMIL BasicLayout only supports pixel units as defined in CSS2. It allows the author to leave out the "px" unit qualifier in pixel values (the "px" qualifier is required in CSS2). Conflicts between the region size attributes bottom, left, right, top, width, and height are resolved according to the rules for absolutely positioned, replaced elements in [CSS2]. The default value of bottom attribute is auto.
fit
This attribute specifies the behavior if the intrinsic height and width of a visual media object differ from the values specified by the height and width attributes in the region element. This attribute does not have a one-to-one mapping onto a CSS2 property, but may be simulated in CSS2.
This attribute may have the following values:
fill
Scale the object's height and width independently so that the content just touches all edges of the box.
hidden
Has the following effect:
  • If the intrinsic height (width) of the media object element is smaller than the height (width) defined in the region element, render the object starting from the top (left) edge and fill up the remaining height (width) with the background color.
  • If the intrinsic height (width) of the media object element is greater than the height (width) defined in the region element, render the object starting from the top (left) edge until the height (width) defined in the region element is reached, and clip the parts of the object below (right of) the height (width).
meet
Scale the visual media object while preserving its aspect ratio until its height or width is equal to the value specified by the height or width attributes, while none of the content is clipped. The object's left top corner is positioned at the top-left coordinates of the box, and empty space at the right or bottom is filled up with the background color.
meetBest
The semantic of this value is identical to meet except that the image is not scaled to greater than 100% in either dimension. This limits degradation of upwardly-scaled media content.
scroll
A scrolling mechanism should be invoked when the element's rendered contents exceed its bounds.
slice
Scale the visual media object while preserving its aspect ratio so that its height or width are equal to the value specified by the height and width attributes while some of the content may get clipped. Depending on the exact situation, either a horizontal or a vertical slice of the visual media object is displayed. Overflow width is clipped from the right of the media object. Overflow height is clipped from the bottom of the media object.

The default value of fit is hidden.

Note that the fit attribute applies to visual media once it has an intrinsic two-dimensional size, such as images and video. It does not apply to visual media that is rendered and adapted to varying circumstances, such as the visual display of HTML, until its two-dimensional spatial dimensions have been determined, such as after an HTML page has been laid out to specific size.

height
The use and definition of this attribute are identical to the "height" property in the CSS2 specification. Attribute values follow the same restrictions and rules as the values of the bottom attribute. The intrinsic height of a region is the same as that of the parent geometry. The default value of the height attribute is auto.
left
The use and definition of this attribute are identical to the "left" property in the CSS2 specification. Attribute values follow the same restrictions and rules as the values of the "bottom" attribute. The default value of the left attribute is auto.
regionName
This attribute assigns a name to this region element that can be referred to by the region attribute of media object elements. The regionName attribute is not a unique identifier; multiple region elements can share the same regionName attribute value. This attribute does not have a default value.
right
The use and definition of this attribute are identical to the "right" property in the CSS2 specification. Attribute values follow the same restrictions and rules as the values of the "bottom" attribute. The default value of right attribute is auto.
showBackground
This attribute controls whether the backgroundColor of a region is shown when no media is being rendered to the region:
  • If the value of showBackground is always, then the background color will be shown in the region when no media object is rendering into that region. If the region is part of a hierarchical sub-region layout, then any ancestor regions must also either be active or have a showBackground value of always for the background color to be shown.
  • If the value of showBackground is whenActive, then the background color will be not be shown in the region when no media object is rendering into that region. If the region is part of a hierarchical sub-region layout, then the background color will also be shown when any descendent regions are active.
The default value of showBackground is always.
top
The use and definition of this attribute are identical to the "top" property in the CSS2 specification. Attribute values follow the same restrictions and rules as the values of the bottom attribute. The default value of the top attribute is auto.
width
The use and definition of this attribute are identical to the "width" property in the CSS2 specification. Attribute values follow the same restrictions and rules as the values of the bottom attribute. The intrinsic width of a region is the same as that of the parent geometry. The default value of width attribute is auto.
z-index
The use and definition of this attribute are identical to the "z-index" property in the CSS2 specification, with the following exception:

If two boxes generated by elements A and B have the same stack level, then:
  • If the display of an element A starts later than the display of an element B, the box of A is stacked on top of the box of B (temporal order).
  • Else, if the display of the elements starts at the same time, and an element A occurs later in the SMIL document text than an element B, the box of A is stacked on top of the box of B (document tree order as defined in CSS2).

A profile integrating the SMIL BasicLayout module must provide a means of declaring an XML identifier on region elements.

Element examples

This section is informative.

In the following example fragment, the position of a text element is set to a 5 pixel distance from the top border of the rendering window:

<smil xmlns="http://www.w3.org/ns/SMIL" version="3.0" baseProfile="Language">
<head>
...
<layout>
...
<region xml:id="a" top="5" />
...
</layout>
</head>
<body>
...
<text region="a" src="text.html" dur="10s" />
...
</body>
</smil>

The root-layout element

The root-layout element determines the value of the layout properties of the root element, which in turn determines the size of the window in which the SMIL presentation is rendered.

If more than one root-layout element is parsed within a single layout element, this is an error, and the document should not be displayed. This does not include root-layout elements skipped by the user agent (e.g. because the enclosing layout element was skipped due to an unrecognized type or because a test attribute evaluated to false).

The semantics of the root-layout element are as in SMIL 1.0: the attributes of the root-layout element determine the size of the top level presentation window, and the declared sibling regions are arranged within this top level window. If either the height or width of the root-layout element is not specified, the value of the attribute is implementation-dependent.

Element attributes
backgroundColor
Defined in backgroundColor under the region element. Note that the effective default behavior is transparent, which implies that, by default, the implementation-dependent window background will be shown.
background-color
Deprecated. Defined in background-color under the region element.
backgroundOpacity
Defined in backgroundOpacity under the region element.
height
Sets the height of the root element. Only length values are allowed. For "length" values, SMIL BasicLayout only supports pixel units as defined in CSS2. It allows the author to leave out the "px" unit qualifier in pixel values (the "px" qualifier is required in CSS2).
width
Sets the width of the root element. Only length values are allowed. For "length" values, SMIL BasicLayout only supports pixel units as defined in CSS2. It allows the author to leave out the "px" unit qualifier in pixel values (the "px" qualifier is required in CSS2).
Element content

The root-layout element is an empty element. This element supports the SMIL 1.0 syntax where the root-layout element is an empty sibling of the top level region elements.

Element examples

This section is informative.

The following example extends the fragment above with a specification of the root-layout element:

<smil xmlns="http://www.w3.org/ns/SMIL" version="3.0" baseProfile="Language">
<head>
<layout>
<root-layout width="320" height="480" />
<region xml:id="a" top="5" />
</layout>
</head>
<body>
<text region="a" src="text.html" dur="10s" />
</body>
</smil>

Note that the root-layout element is placed at a peer-level within the layout section. SMIL Layout also supports a nested containment model using the topLayout element defined in the MultiWindowLayout module.

The region attribute

The region attribute is added to the ref element (and its synonyms). The target of this attribute will be one or more regions with a regionName declared that matches the value of this attribute, or a single region element with a region attribute that matches this value. For processing rules, see the section Implementation details.

7.4.3 SMIL BasicLayout Implementation and Integration

Implementation Details

SMIL BasicLayout module is consistent with the visual rendering model defined in CSS2, it reuses the formatting properties defined by the CSS2 specification, and newly introduces the fit attribute [CSS2]. The reader is expected to be familiar with the concepts and terms defined in CSS2.

SMIL layout regions influence the propagation of user interface events (such as a mouse click, or hyperlink activation) to underlying visible elements. When the location of an event corresponds to the background of a region rather than the media that is displayed in that region, a region background color of transparent allows user interface events to pass through to elements lower in the display stacking order. Conversely, regions with non-transparent background colors will capture user interface events, not allowing the event to pass through to elements lower in the display stacking order. This behavior is separate from that of a language profile's ability to make use of user interface events captured by region elements.

An element that does not refer to a valid region element will display in the default region. If not otherwise specified by the profile, the default region is defined as filling and aligned to the upper-left corner of the presentation window. This default region takes on default values for all other region attributes.

The region attribute is applied to an element in order to specify which rendering region is assigned to the element. The attribute refers to the abstract rendering region (either visual or acoustic) defined within the layout section of the document. The referenced abstract rendering region is determined by applying the following rules, in order:

  1. Find all elements in the layout section with regionName attributes that are assigned the same value as that of the region attribute.
  2. Remove the elements from this collection that are removed from the rendered presentation due to the processing of switch elements and test attributes.
  3. If any elements remain, the media should be rendered in all of the referred to regions. If the implementation cannot render the media simultaneously in multiple regions, then the media should be rendered using the lexically first remaining element.
  4. If no elements have a regionName attribute that is assigned the same value as that of the region attribute, then select the element in the layout section whose unique identifier is the value of the region attribute.

If this process selects no rendering surface defined in the layout section, the values of the formatting properties of this element are defined by the default layout values, which is described in the section on integration requirements for this module.

The definition of backgroundOpacity and the value transparent for backgroundColor are independent. For example, a combination of backgroundOpacity=100% and backgroundColor=transparent results in a transparent background.

Integration Requirements

A profile integrating the SMIL BasicLayout module must define the content models for the layout element if any elements beyond those specified here are to be allowed as children.

A profile integrating the SMIL BasicLayout module must provide a means of declaring an XML identifier on region elements if the profile intends on referring to region elements by XML identifier. This value is used as the argument value to the region attribute. This is not required if the profile will only use the regionName method of referring to a region element.

A profile integrating the SMIL BasicLayout module must specify which elements have a region attribute and any inheritance of the attribute.

If not otherwise defined by the profile, the default values of the layout attributes listed in the SMIL layout modules will apply to presented elements not otherwise specifying layout semantics.

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

7.4.4 Document Type Definition (DTD) for the BasicLayout Module

See the full DTD for the SMIL Layout modules.

7.5 The SMIL AudioLayout Module

This section is normative.

7.5.1 Overview

In SMIL AudioLayout, one attribute is supported that allows the relative sound intensity of an audio object to be specified via the soundLevel attribute. When used in conjunction with SMIL 3.0 Animation (and if supported by the profile), the value of the attribute may be varied over time.

This section is informative.

The following region defines an audio sound level that is set to -6dB relative to its normal recorded value:

  <layout>
    ...
    <region xml:id="a" soundLevel="-6dB"/>
    ...
  </layout>

The same approximate effect could be obtained by using the attribute's percentage notation:

  <layout>
    ...
    <region xml:id="a" soundLevel="50%"/>
    ...
  </layout>

7.5.2 Audio Volume Control

SMIL AudioLayout module supports control of aural media volumes via a property on the region element, soundLevel. Multimedia assigned to a region with an explicit soundLevel attribute will have its audio rendered at the given relative sound intensity. If the profile integrating this module also include the OverrideLayout module, the soundLevel attribute may also be placed as modifiers on individual media references.

7.5.3 Elements and Attributes

This section defines the soundLevel attribute that makes up the SMIL AudioLayout module.

The region element

The region element defined in the BasicLayout module is extended with the addition of the soundLevel attribute.

Element attributes

The region element may have the following aural attribute:

soundLevel
Specifies the relative volume of the audio portion of a media element assigned to play within the given region. This associates the region element with a sound reproduction unit. Cascaded regions will accumulate their respective sound level settings, as will be explained below. Regions that are used for multiple sources apply their sound level setting to all of them. A sound source may be reproduced by different units, e.g., through application of the regionName attribute. In such a "multiple window" case, a separate soundLevel may be applied to each instance of the sound source, one per region. Sound level settings are as percentage values or in decibels (dB). Assigned level changes accumulate across nested regions by summing values.

Valid values are either non-negative CSS2 percentage values [CSS2], (section 4.3.3) or signed ("+" or "-") CSS2 numbers [CSS2] (section 4.3.1), immediately followed by the suffix "dB".

Percentage values are interpreted relative to the recorded volume of the media. A setting of '0%' plays the media silently. A value of '100%' will play the media at its recorded volume (0 dB). Similarly, a value of '200%' will play the media nearly twice as loud (6 dB) as its recorded volume (subject to hardware limitations). The default value is '100%'.

Decibel values are interpreted relative to the recorded volume of the media. The values are interpreted as a ratio of the squares of the new signal amplitude (a1) and the recorded amplitude (a0), and are defined in terms of dB:

soundLevel(dB) = 10 log10 (a1*a1 / a0*a0) = 20 log10 (a1 / a0)

A setting of a large negative value effectively plays the media silently. A value of '-6.0dB' will play the media at approximately half the amplitude of its recorded signal amplitude, and is equivalent to a percentage value of 50%. Similarly, a value of '+6dB' will play the media at approximately twice the amplitude of its recorded signal amplitude (subject to hardware limitations), and is equivalent to a percentage notation of 200%. The default value is '+0.0dB', which specifies no change to the recorded signal amplitude.

The absolute sound level of media perceived is further subject to system volume settings, which cannot be controlled with this attribute.

7.5.4 Integration Requirements for the AudioLayout Module

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

7.5.5 Document Type Definition (DTD) for the AudioLayout Module

See the full DTD for the SMIL Layout modules.

7.6 The SMIL MultiWindowLayout Module

This section is normative.

7.6.1 Overview

This section defines the functionality in the SMIL MultiWindowLayout module. This level contains elements and attributes providing for creation and control of multiple top level windows on the rendering device.

In the architecture of the SMIL BasicLayout module, each presentation is rendered into a single root window of a specific size/shape. The root window contains all of the regions used to manage the rendering of specific media objects and is defined by a peer-level root-layout element.

The SMIL Layout specification extends the root container level with the notion of a top-level rendering window, called a topLayout window. A SMIL layout section may support one or more topLayout windows. The assignment of the regions to individual top level windows allows independent placement and resizing of each top-level window, if supported by the including profile and implementation. The initial placement of the top level windows on the display device and any available means of relocating the top level windows is implementation-dependent.

The top-level windows function as rendering containers only, that is, they do not carry temporal significance. In other words, each window does not define a separate timeline or any other time-container properties. There is still a single master timeline for the SMIL presentation, no matter how many top-level windows have been created. This is important to allow synchronization between media displayed in separate top-level windows.

The display of top level windows can be controlled automatically by the player, or manually by the user of the application. If a window is closed (by the user) while any of the elements displayed in that window are active, there is no effect on the timeline (if any) of those elements. However, a player may choose not to decode content as a performance improvement. The means provided to a user to close top level windows is implementation-dependent.

For SMIL 1.0 compatibility, the root-layout element will continue to support SMIL 1.0 layout semantics. The new topLayout element will support the extension semantics and the improved, nested syntax.

Note also that any one region may belong to at most one top-level (or root-level) window. Regions not declared as children of a topLayout element belong to the root-layout window. If no root-layout element has been declared, the region is assigned to an additional window according to the semantics in the BasicLayout module.

7.6.2 Elements and Attributes

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

The topLayout element

The topLayout element determines the size of the a window in which the SMIL presentation is rendered, as well as serving as a top level window in which to place child region elements.

Multiple topLayout elements may appear within a single layout element, each declaring an independent top-level window.

Each instance of a topLayout element determines the size of a separate top-level presentation window, and the descendant regions are arranged within this top-level window and relative to the coordinate system of this window.

This module also provides control over when topLayout windows open and close in a presentation. Note that the precise mapping of topLayout windows on to the host environment is implementation-dependent. It is expected that implementations will "pop up" independent desktop windows if they can, but other means of supporting multiple topLayouts, such as by using frames, are allowed. When automatically opening and closing windows, applications should try to comply with the WAI User Agent Guidelines [UAAG] and allow the user to choose whether to be warned that windows are being opened and closed, and give a method for disabling automatic opening and closing of windows.

Element attributes
backgroundColor
Defined in backgroundColor under the region element. Note that the effective default behavior is transparent, which implies that, by default, the implementation-dependent window background will be shown.
backgroundOpacity
Defined in backgroundOpacity under the region element.
close
Specifies when the top level window should be closed. If the value of close is onRequest, then the top level window should not be closed automatically by the player and will only close if the user explicitly closes it via the user interface. If the value of close is whenNotActive, then the top level window should close automatically when no media is being displayed in any one of the window's regions. For timed media using the SMIL timing and synchronization modules, this means when there is no media within its active duration or freeze period using any region of the topLayout. The default value of close is onRequest.
height
Sets the height of the top-level window. Only length values are allowed. For "length" values, SMIL MultiWindowLayout only supports pixel units as defined in CSS2. It allows the author to leave out the "px" unit qualifier in pixel values (the "px" qualifier is required in CSS2).
open
Specifies when the top level window should be opened. If the value of open is onStart, then the top level window should be opened when the presentation begins, and if closed, should not be reopened automatically during the presentation. If the value of open is whenActive, then, if not already open, the top level window should be opened when media is displayed in one of the window's regions. For timed media using the SMIL timing and synchronization modules, this means when there is any media within its active duration or freeze period using any region of the topLayout. The default value of open is onStart.
width
Sets the width of the top-level window. Only length values are allowed. For "length" values, SMIL MultiWindowLayout only supports pixel units as defined in CSS2. It allows the author to leave out the "px" unit qualifier in pixel values (the "px" qualifier is required in CSS2).
Element content

The topLayout element may contain any number of region elements, or be empty.

Element examples

This section is informative.

The following example provides a restatement of the root-layout example:

<smil xmlns="http://www.w3.org/ns/SMIL" version="3.0" baseProfile="Language">
  <head>
    <layout>
      <topLayout width="320" height="480" />
        <region xml:id="a" top="5" />
      </topLayout/>
    </layout>
  </head>
  <body>
    <text region="a" src="text.html" dur="10s" />
  </body>
</smil>

Multiple instances of the topLayout element may occur within a single layout element:

  <layout>
    <topLayout xml:id="WinV" title="Video" width="320" height="240"/>
      <region xml:id="pictures" title="pictures" height="100%" fit="meet"/>
    </topLayout>
    <topLayout xml:id="WinC" title="Captions" width="320" height="60">
      <region xml:id="captions" title="caption text" top="90%" fit="meet"/>
    </topLayout>
  </layout>

In this example, two top-level windows are defined ("WinV" and "WinC"), and two regions are defined with one region ("pictures") assigned to WinV and the other ("captions") to WinC. These windows may be opened and closed independently by the presentation or by a user.

The layout element

The MultiWindowLayout module does not redefine the BasicLayout layout element. Instead, it simply extends the content model for that element, as described in the following subsection.

Element content

The layout element defined in the SMIL BasicLayout module is extended by adding topLayout element to the content model of the layout element if the type attribute of the layout element has the value "text/smil-basic-layout".

7.6.3 MultiWindowLayout Module Events

This module includes two events that may be included in the integrating language profile.

topLayoutOpenEvent
Raised when a topLayout window opens. This event is delivered to the associated topLayout element. If a topLayout closes and then reopens when additional media becomes active in any of its regions, this event will be raised again, and will be raised every subsequent time it reopens.
topLayoutCloseEvent
Raised when a topLayout closes for any reason. This event is delivered to the associated topLayout element. If a topLayout reopens when additional media becomes active in any of its regions, this event will be raised again if and when the topLayout closes again, and will be raised every subsequent time it closes.

7.6.4 Implementation and Integration Requirements for the MultiWindowLayout Module

Implementation details

Allowing multiple topLayout elements within a single layout element implies support for multiple top level windows. If an implementation does not support multiple top level windows (because of device or processing restrictions), only content in the first top-level window defined in the layout will be rendered. Non-rendered objects will still participate in all SMIL timing and scheduling operations.

If used together with the root-layout element, any direct peer-level regions to the root-layout will be contained within the extents of the root-layout.

7.6.5 Integration Requirements for the MultiWindowLayout Module

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

The language profile must specify the declarative names for binding the topLayoutOpenEvent and topLayoutCloseEvent events described in the MultiWindowLayout Module Events section, as well as the bubbling behavior of the events.

7.6.6 Document Type Definition (DTD) for the MultiWindowLayout Module

See the full DTD for the SMIL Layout modules.

7.7 The SMIL SubRegionLayout Module

This section is normative.

7.7.1 Overview

The SubRegionLayout module defines two mechanisms for defining regions that are logically contained within a parent region (these are SMIL's sub-regions). First, the SubRegionLayout module extends the definition of the region element to allow for the specification of sub-regions within the layout section as hierarchical content of regions. Second, the SubRegionLayout module extends the attributes allowed on (media) object references to allow a dynamic sub-region to be defined in-line by that object instance only. All values given for placement within sub-regions are defined in terms of the parent region's placement attributes. The ability to define sub-regions may be exploited for authoring convenience or when changing the location of a group of related regions using SMIL Animation.

This section is informative.

In the following fragment, a parent region (CaptionedVideo) is defined that contains two hierarchical sub-regions: image and captions. The placement of the image and caption content is specified as relative to the dimensions of the parent region. This is an example of a statically-defined hierarchy of sub-regions.

  <layout>
     ...
     <region xml:id="CaptionedVideo" top="10px" left="20px" width="320" height="300">
       <region xml:id="image" title="image content" width="100%" height="240px" fit="meet"/>
       <region xml:id="captions" title="caption text" top="240px" height="60px" fit="meet"/>
     </region>
     ...
  </layout>

A presentation using the above layout specification could also create a dynamic sub-region that is defined for use by this single object:

  <body>
      ...
     <img xml:id="Title" region="image" top="5%" left="3" bottom="10%" right="15%"  src="TitleImage.png"/>
     ...
  </body>

This statement creates a sub-region with the named region "image" with the given extents. In the example above, the effective boundaries of the sub-region for the placement of this object are defined by declaring the top, bottom, left and right edges of the region to the values shown, and then filling the resulting sub-region with the specified image as directed by the fit attribute. If the size of the media object being displayed is smaller than that of the resulting sub-region, the display will be similar to: picture of sub-regions

The use of in-line sub-region placement is intended as a light-weight alternative to defining a large number of single-use regions. Often, the dimensions used for the sub-region will match the dimensions of the media object being placed, but in all cases the values of the fit attribute will govern rendering of the object in the sub-region. The other attributes on the media element that would have been applied to a referenced region are applied to the sub-region instead. Note that the default values for the sub-region attributes are all 'auto', meaning that, by default, a sub-region is created having the same size and position as the parent region.

The use of sub-region positioning leads to authoring convenience and SMIL file compactness, since many separate regions do not need to be defined to handle incidental layout needs. The support for a hierarchy of sub-regions also allows multiple layout objects to be animated in concert by moving the parent region using SMIL Animation facilities.

7.7.2 Elements and attributes

This section defines extensions to the region and ref elements (and its synonyms) to support sub-region functionality.

The region element

This module extends the definition of the region element to include the definition of hierarchical sub-regions.

Element attributes

In the SubRegionLayout module, the region element has no additional attributes beyond that provided in the other included layout modules. However, the semantics of the z-index attribute are extended to support hierarchical sub-regions.

z-index
This attribute is defined as in the BasicLayout module with extensions presented here.
The z-index attribute defines the level of the region within the parent region stacking context. Elements assigned to higher level regions are rendered in front of lower level regions within the same parent region. Child regions are always placed in front of their parent region. This results in a two stage sorting of region visibility: first by parent-child containment, and then by z-index among siblings.

Just as with simple non-hierarchical regions, the stacking order of hierarchical regions may be affected by temporal activation. A region becomes active either when media begins rendering into it, or when one of its child regions becomes active. If two sibling regions have the same z-index, the region most recently made active is in front of the other region.

Element content

The SMIL SubRegionLayout module extends the region element content model to include region elements.

The ref element (and its synonyms)

The SubRegionLayout module extends the ref element to allow a separate, unnamed sub-region to be defined for the media object reference containing the sub-region positioning attributes.

Element attributes

The ref element defined in the MediaObject module and its synonyms are extended to include the following positioning attributes.

top
This value uniquely identifies the position or the distance (using CSS2 pixel or non-negative percentage values) of the top edge of the sub-region relative to the top of the region. The "px" unit qualifier in pixel values may be omitted. The default value of top is auto.
bottom
This value uniquely identifies the position or the distance (using CSS2 pixel or non-negative percentage values) of the bottom edge of the sub-region relative to the bottom of the region. The "px" unit qualifier in pixel values may be omitted. The default value of bottom is auto.
height
This value uniquely identifies the position or the distance (using CSS2 pixel or non-negative percentage values) of the bottom edge of the sub-region relative to the top side of the sub-region. The "px" unit qualifier in pixel values may be omitted. The default value of height is auto.
left
This value uniquely identifies the position or the distance (using CSS2 pixel or non-negative percentage values) of the left edge of the sub-region relative to the left of the region. The "px" unit qualifier in pixel values may be omitted. The default value of left is auto.
right
This value uniquely identifies the position or the distance (using CSS2 pixel or non-negative percentage values) of the right edge of the sub-region relative to the right side of the region. The "px" unit qualifier in pixel values may be omitted. The default value of right is auto.
width
This value uniquely identifies the position or the distance (using CSS2 pixel or non-negative percentage values) of the right edge of the sub-region relative to the left side of the sub-region. The "px" unit qualifier in pixel values may be omitted. The default value of width is auto.

Conflicts between the region size attributes bottom,height, left, right, top, and width are resolved according to the rules for placeholder elements described in the section on the region element.

The sub-region positioning attributes will be ignored if they are used on an element without a region attribute (or, if supported, the regionName attribute) that resolves to a region element in the layout section.

7.7.3 SubRegionLayout Module Events

This module does not define any SMIL events.

7.7.4 SubRegionLayout Implementation and Integration

Implementation Details

The position of a region, as specified by its top and left attributes, is always relative to the parent geometry, which is defined by the parent element. For the SMIL SubRegionLayout module, all hierarchical region elements must have as their immediate parent a region or topLayout element. The position of the hierarchical region is defined relative to that parent element. The intrinsic size of a region is equal to the size of the parent geometry.

When region sizes, as specified by width and height attributes are declared relative with the "%" notation, the size of the hierarchical region is relative to the size of the parent region. Sizes declared as absolute pixel values are absolute values even when used with a child region.

Note that a (hierarchical) region may be defined in such a way as to extend beyond the limits of its parent. In this case the child region must be clipped to the parent boundaries.

If a z-index attribute is defined on the hierarchical region, it is evaluated as a local index within that of the parent.

If the fit attribute and alignment attributes regPoint and regAlign are relevant to the placement of a particular media object, the interaction is the same as described in the definition of regPoint. If sub-region positioning attributes are used on a media object along with fit or the alignment attributes regPoint and regAlign, these attributes apply to the sub-region. In this case the fit setting on the referenced region element does not apply to the sub-region.

For both sub-region positioning and registration point use (as defined in the module), the value of the z-index attribute on the associated region is used. If media objects overlap spatially, existing rules for resolving z-index conflicts are applied.

Note that placement within the region may be defined in such a way as to extend the media object beyond the limits of the region. In this case the media object must be clipped to the region boundaries.

If two hierarchical regions with the same z-index attribute value overlap, the existing rules for z-index processing defined in the BasicLayout module are applied. Specifically, the rule concerning time priority is maintained, meaning that in the case of a z-index conflict, the media visible in the overlap will be determined by the region that is rendering the media that has most recently begun in time. If the conflicting media began at the same time, then the rule using the textual order of the media elements in the SMIL document is applied.

This section is informative.

For example:

<layout> 
   <root-layout width="640px" height="480px" />
   <region xml:id="whole" top="0px" left="0px" width="640px" 
                                height="480px" z-index="5"/>
   <region xml:id="right" top="0px" left="320px" width="320px"
                                height="480px" z-index="4">
       <region xml:id="inset" top="140px" left="80" width="160px" 
                                height="200px" z-index="6"/>
       <region xml:id="inset2" top="140px" left="80" width="160px" 
                                height="200px" z-index="6"/>
       <region xml:id="inset3" top="140px" left="80" width="160px" 
                                height="200px" z-index="7"/>
   </region>
</layout>
...
<par>
        <img xml:id="A" region="whole" src="imageA.jpg" dur="10s"/>
        <img xml:id="B" region="inset" src="imageB.jpg" dur="10s"/>
</par>
<par>
        <img xml:id="D" region="inset2" src="imageD.jpg" begin="1s" dur="10s"/>
        <img xml:id="C" region="inset" src="imageC.jpg" begin="0s" dur="10s"/>
</par>
<par>
        <img xml:id="E" region="inset2" src="imageE.jpg" dur="10s"/>
        <img xml:id="F" region="inset3" src="imageF.jpg" dur="10s"/>
</par>
  1. In the first "par", image "A" and image "B" begin at the same time. Image A will obscure image "B", even though the z-index of "inset" is greater than that of "whole". This is because the z-index of "right", which is the region containing "inset" is less than that of "whole".
  2. In the second "par", images "C" and "D" are rendered into regions occupying the same area of the rendering surface. Image "C" will be shown for one second and then obscured by Image "D", since "D" begins after image "C". Note that lexical order is irrelevant here.
  3. In the third "par", the z-index of region "inset" is considered when computing stacking between siblings, and therefore image "F" will be shown, but image "E" will be obscured for the entire 10 seconds that they are both active.

Integration Requirements for the SubRegionLayout Module

The functionality in this module builds on top of the functionality in the BasicLayout module and the MediaObject module, which are required prerequisites for inclusion of the SubRegionLayout module. If the functionality in this module is to be used with the topLayout construct, the MultiWindowLayout module is a prerequisite.

7.7.5 Document Type Definition (DTD) for the SubRegionLayout Module

See the full DTD for the SMIL Layout modules.

7.8 AlignmentLayout Module

This section is normative.

7.8.1 Overview

A registration element is an element defined within this module that is used to define a point within a region and a default object alignment algorithm about that point. The element may be used in a media object element, where it is associated with a region and an optional override alignment algorithm. The placement values within registration elements can be either percentages or pixels.

The use of registration points allows for consistent relative placement across regions. As such, registration points are defined outside of any single region.

Registration points may be used to coordinate the placement of a set of media objects that do not share the same sizes. (For example, a set of images may be aligned to the center of a region.) They can also be used to coordinate the display of images about a particular point in a region.

For authoring convenience, SMIL AlignmentLayout module provides several pre-defined region registration points including topLeft, topMid, topRight, midLeft, center, midRight, bottomLeft, bottomMid, and bottomRight.

As a further convenience, SMIL AlignmentLayout module provides the mediaAlign attribute, which defines a combination of regAlign and regPoint attributes. For example, media objects may be centered in any region using mediaAlign as follows:

    <ref ... mediaAlign="center" />

If the mediaAlign attribute and either (or both) of the regPoint and regAlign attributes are used together, the regPoint and/or regAlign value(s) will override the corresponding effective regPoint/regAlign value(s) defined by the mediaAlign value.

The default value of regAlign for a region is topLeft. If the regAlign attribute is used without a regPoint attribute, the alignment operation is relative to the upper left point of the region containing this object, that is, the behavior is the same as if the regPoint were to be specified as topLeft.

Rules for handling clipping of objects within regions based on the regPoint and regAlign attributes are defined below.

This section is informative.

An example is given in the following code of two registration points (with id values "midPoint" and "topMargin"), one of which is defined as a relative location and one at a fixed pixel location, using the SMIL AlignmentLayout syntax:

    <layout>
<regPoint xml:id="midPoint" top="50%" left="50%" regAlign="center" />
<regPoint xml:id="topMargin" top="10" left="15" regAlign="topLeft" />
<region xml:id="a" ... />
<region xml:id="b" ... />
</layout>

In this example, the registration point with the id value "midPoint" has a default alignment algorithm that centers the media object about the defined point, while the registration point with the id value "topMargin" has a default alignment algorithm that places the top-left point of the media object at the registration point.

Various media elements could be displayed in the regions using the alignment points as follows:

  
<ref region="a" src="rtsp://..." dur="2s" regPoint="midPoint" />
<ref region="b" src="http://..." dur="2s"
regPoint="midPoint" regAlign="bottomRight"/>
<ref region="a" src="http://..." dur="2s" regPoint="topMargin" />
<ref region="b" src="http://..." dur="2s"
regPoint="topMargin" regAlign="center"/>

In the first example, a media object is centered in the middle of regiona. In the second example, a media object has its bottom right corner centered in the middle of region b. Similarly, in the third example, a media object has its top left corner placed at a point 10,15 within region a, and in the fourth example, an object is centered around the point 10,15 in region b.

The following example illustrates how images may be aligned at a particular point in a region:

   <layout>
<regPoint xml:id="middle" top="50%" left="50%" regAlign="center" />
<region xml:id="a" ... />
</layout>
...
<seq>
<ref region="a" src="rtsp://..." dur="2s" regPoint="middle"
regAlign="bottomRight"/>
<ref region="a" src="http://..." dur="2s" regPoint="middle"
regAlign="bottomLeft"/>
<ref region="a" src="http://..." dur="2s" regPoint="middle"
regAlign="topLeft"/>
<ref region="a" src="http://..." dur="2s" regPoint="middle"
regAlign="topRight"/>
</seq>

In this example, four objects are aligned over time to the middle of region. If any media element extends outside the bounds of a region, it will be clipped to the region.

In the following example, media objects may be centered in any region using pre-defined registration and alignment points:

    <ref ... regPoint="center" regAlign="center" />

Note that registration points are global within the context of a layout, and are not tied to a particular region, but can be reused across regions. As such, pixel-based offsets should be used with care.

7.8.2 Elements and Attributes for the AlignmentLayout Module

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

The layout element

This element extends the content model of the layout element to support the registration point functionality described in this section.

Element content

If the type attribute of the layout element has the value "text/smil-basic-layout", it is extended to contain the following elements:

region
root-layout
regPoint

The regPoint element

The regPoint element determines the (x, y) coordinates of a point relative to a region upper-left corner for use in aligning elements in the document's body on regions within a visual rendering surface. A regPoint may be defined using absolute (pixel) or relative (percentage) based values. The regPoint functionality is not defined and may not be used for media without intrinsic size.

For the purposes of regPoint functionality, media and regions are defined to be rectangular, with perpendicular sides, with the sides ordered clockwise top, right, bottom, and left. The top side is the edge closest to the point or edge of the display device considered "up".

Element attributes
top
This value uniquely identifies the position or the distance (using CSS2 pixel or non-negative percentage values) of the registration point relative to the top of the region. The "px" unit qualifier in pixel values may be omitted. The default value of top is auto.
bottom
This value uniquely identifies the position or the distance (using CSS2 pixel or non-negative percentage values) of the registration point relative to the bottom of the region. The "px" unit qualifier in pixel values may be omitted. The default value of bottom is auto.
left
This value uniquely identifies the position or the distance (using CSS2 pixel or non-negative percentage values) of the registration point relative to the left location of the region. The "px" unit qualifier in pixel values may be omitted. The default value of left is auto.
right
This value uniquely identifies the position or the distance (using CSS2 pixel or non-negative percentage values) of the registration point relative to the right location of the region. The "px" unit qualifier in pixel values may be omitted. The default value of right is auto.
regAlign
This attribute specifies the default alignment algorithm which is associated with a regPoint relative to the media object. The value of topLeft is the default. The following values are allowed:
topLeft
Align the top-left corner of the object with the registration point.
topMid
Align the top-middle point of the object with the registration point. The top-middle is the point offset width/2 to the right of the object top-left corner.
topRight
Align the top-right corner of the object with the registration point.
midLeft
Align the middle-left point of the object with the registration point. The middle-left is the point offset height/2 down from the object top-left corner.
center
Align the center of the object with the registration point.
midRight
Align the middle-right point of the object with the registration point. The middle-right is the point offset height/2 down from the object top-right corner.
bottomLeft
Align the bottom-left corner of the object with the registration point.
bottomMid
Align the bottom-middle point of the object with the registration point. The bottom-middle is the point offset width/2 right from the object bottom-left corner.
bottomRight
Align the bottom-right corner of the object with the registration point.
Element content

None.

The region element

This module extends the definition of the region element to include the definition of default alignment policies for content in that region.

Element attributes
regPoint
This attribute is identical to the regPoint attribute on media objects defined below, except that it defines a default alignment point for all media objects placed in the region. The default value for this attribute when used on the region element is topLeft.
regAlign
This attribute is identical to the regAlign attribute on media objects defined below, except that it defines a default alignment policy for all media objects placed in the region. The default value for this attribute when used on the region element is topLeft.
mediaAlign
This attribute is identical to the mediaAlign attribute on media objects defined below, except that it defines a default combination registration point/alignment policy for all media objects placed in the region. The default value for this attribute when used on the region element is undefined; the default behavior of this attribute is the behavior resulting from the application of the regPoint and regAlign attributes. (Note that this defines an effective default behavior of topLeft.)
soundAlign
This attribute is identical to the soundAlign attribute on media objects defined below, except that it defines a default 2D placement of the audio portion of a media element assigned to play within the given region. The default value for this attribute when used on the region element is both.
Element content

SMIL AlignmentLayout module does not extend the region element content model.

The ref element (and its synonyms)

The AlignmentLayout module extends the ref element to allow the positioning of media content within a region based on the an alignment registration point and an alignment policy.

Element attributes

The ref element defined in the MediaObject module is extended to include the mediaAlign and regPoint attributes, both in conjunction with the regPoint element. If a regPoint attribute is missing or refers to a non-existent regPoint element the value of the regAlign attributes are applied to the top-left point of the region containing the media object.

regPoint
This value uniquely identifies the registration point to be used for the placement of the object. The value should be an XML identifier of a regPoint element.
The following values are predefined registration points that do not have to be declared as regPoint elements before they are used:
topLeft
Same as using top="0%" left="0%" on the element without the regPoint attribute.
topMid
Same as using top="0%" left="50%" on the element without the regPoint attribute.
topRight
Same as using top="0%" left="100%" on the element without the regPoint attribute.
midLeft
Same as using top="50%" left="0%" on the element without the regPoint attribute.
center
Same as using top="50%" left="50%" on the element without the regPoint attribute.
midRight
Same as using top="50%" left="100%" on the element without the regPoint attribute.
bottomLeft
Same as using top="100%" left="0%" on the element without the regPoint attribute.
bottomMid
Same as using top="100%" left="50%" on the element without the regPoint attribute.
bottomRight
Same as using top="100%" left="100%" on the element without the regPoint attribute.
Note that the predefined registration points have the same meaning relative to the region as the regAlign attribute values have relative to the media. The default value is inherited from the regPoint value defined for the associated region. This implies a default behavior of topLeft.
regAlign
This value uniquely identifies the registration algorithm to be used for the regPoint defined for the object, and overrides any regAlign attribute on the referenced regPoint element. Permissible values are those defined under the regAlign attribute for the regPoint element. If used without an explicit regPoint attribute, the value is relative to the top left point of the region used by the associated media object. The default value is inherited from the regAlign value defined for the associated region. This implies a default behavior of topLeft.
mediaAlign
This value uniquely identifies a short-hand notation for combining set combinations of regAlign and regPoint attributes. Valid values are:
topLeft
Same as using the regPoint ="topLeft" and regAlign="topLeft" attributes.
topMid
Same as using the regPoint ="topMid" and regAlign="topMid" attributes.
topRight
Same as using the regPoint ="topRight" and regAlign="topRight" attributes.
midLeft
Same as using the regPoint ="midLeft" and regAlign="midLeft" attributes.
center
Same as using the regPoint ="center" and regAlign="center" attributes.
midRight
Same as using the regPoint ="midRight" and regAlign="midRight" attributes.
bottomLeft
Same as using the regPoint ="bottomLeft" and regAlign="bottomLeft" attributes.
bottomMid
Same as using the regPoint ="bottomMid" and regAlign="bottomMid" attributes.
bottomRight
Same as using the regPoint ="bottomRight" and regAlign="bottomRight" attributes.
If specified together with either (or both) of the regPoint and/or regAlign attributes, the effect values of the respective positioning attribute(s) specified by mediaAlign will be overridden by the values given for regPoint and/or regAlign. This attribute does not have a default value; the default behavior is inherited from the effective values of the regPoint and regAlign attributes.
soundAlign
Specifies the coarse 2D placement of the audio portion of a media element assigned to play within the given region. The default value is inherited from the region. The following values are allowed:
both
Place the audio on both channels. If stereo or other dual-channel audio is used, the audio will be reproduced on both channels, implementation permitting.
left
Place the audio on the left channel only. If stereo audio is used, only the left source audio will be reproduced on the left audio channel, implementation permitting.
right
Place the audio on the right channel only. If stereo audio is used, only the right source audio will be reproduced on the right audio channel, implementation permitting.
Element content

SMIL AlignmentLayout module does not extend the ref element content model.

7.8.3 AlignmentLayout Module Events

This module does not define any SMIL events.

7.8.4 SMIL AlignmentLayout Implementation and Integration

Implementation Details

If an implementation cannot support the soundLevel attribute, it may be ignored. Even when processing is ignored, the attribute must be correctly parsed.

The regPoint element may only appear as an immediate child of a layout element.

If the registration point functionality is used on a media object that also uses sub-region positioning, the registration point applies to the subregion.

For registration point use, the value of the z-index attribute on the associated region is used. If media objects overlap spatially, existing rules for resolving z-index conflicts are applied.

Note that placement within the region may be defined in such a way as to extend the media object beyond the limits of the region. In this case the media object must be clipped to the region boundaries.

The default value of regAlign for a region is topLeft. If the regAlign attribute is used without a regPoint attribute, the alignment operation is relative to the upper left point of the region containing this object, that is, the behavior is the same as if the regPoint were to be specified as topLeft.

If the registration point or alignment functionality is used on a media object, the interaction between the regPoint attribute value, the regAlign attribute value, and the fit attribute value of the region in which the media object is displayed is as follows:

fill fit value:
This depends on the value of the regAlign attribute. (Note: in all cases, the media must maintain proper alignment over the regPoint):
topLeft regAlign value:
Scale the object's height and width independently so that the content just touches the bottom and right edges of the box.
topMid regAlign value:
Scale the object's height and width independently so that the content just touches the bottom edge of the box, and the nearest (to the regPoint