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:

• Define an XML-based language that allows authors to write interactive multimedia presentations. Using SMIL 3.0, an author can describe the temporal behavior of a multimedia presentation, associate hyperlinks with media objects and describe the layout of the presentation on a screen.
• Allow reusing of SMIL 3.0 syntax and semantics in other XML-based languages, in particular those who need to represent timing and synchronization. For example, SMIL 3.0 components are used for integrating timing into XHTML [XHTML10] and into SVG [SVG].
• Extend the functionalities contained in the SMIL 2.1 [SMIL21] into new or revised SMIL 3.0 modules.
• Define new SMIL 3.0 Mobile Profiles incorporating features useful within the industry.

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.

This section is informative.

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

• Section 2 presents SMIL 3.0 modularization, the individual modules and conformance criteria.
• Section 3 defines SMIL 3.0 Animation.
• Section 4 defines SMIL 3.0 Content Control.
• Section 5 defines SMIL 3.0 Layout.
• Section 6 defines SMIL 3.0 Linking.
• Section 7 defines SMIL 3.0 Media Object.
• Section 8 defines SMIL 3.0 SMILText.
• Section 9 defines SMIL 3.0 Metainformation.
• Section 10 defines SMIL 3.0 Structure.
• Section 11 defines SMIL 3.0 Timing and Synchronization.
• Section 12 defines SMIL 3.0 Time Manipulations.
• Section 13 defines SMIL 3.0 External Timing.
• Section 14 defines SMIL 3.0 DOM.
• Section 15 defines SMIL 3.0 State.
• Section 16 defines SMIL 3.0 Transition effects.

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

• Section 17 defines the SMIL 3.0 Language Profile.
• Section 18 defines the SMIL 3.0 Mobile Profile.
• Section 19 defines the SMIL 3.0 Extented Mobile Profile.
• Section 20 defines the SMIL 3.0 Daisy Profile.
• Section 21 defines the SMIL 3.0 Tiny Profile.

Finally, SMIL 3.0 defines a scalability framework:

• Section 22 defines the SMIL 3.0 Scalability Framework.

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.

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

SMIL3.0 adds the following new sections introducing new modules where new elements or attributes semantics are specified.

• SMIL 3.0 smilText provides a new media type for use in SMIL presentations. Unlike other media types defined in the media object module, smilText provides 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.
• SMIL 3.0 External Timing defines an XML timing language that makes SMIL 3.0 element and attribute timing control available to a wide range of other XML languages. Because of its similarity with external style and positioning descriptions in the Cascading Style Sheet (CSS) language, this functionality has been termed SMIL Timesheets. It can be seen as a temporal counterpart of CSS. Whereas CSS defines the spatial layout of the document and formatting of the elements, SMIL Timesheets specify which elements are active at a certain moment and what their temporal scope is within a document.
• SMIL 3.0 State provides a mechanism for the author to create more complex control flow than what SMIL provides through the timing and content control modules, without using a scripting language. To provide this, it allows a document to have some explicit state (think: variables) along with ways to modify, use and save this state.
• SMIL 3.0 DOM describes the SMIL 3.0 DOM support. SMIL is an XML-based language and conforms to the (XML) DOM Core [DOM1], [DOM2]. A language profile may include DOM support. The granularity of DOM being supported corresponds to the modules being selected in that language profile. As with all modules, required support for the DOM is an option of the language profile. DOM support consists of two independently usable parts, a module which contains methods to start and stop parts of a presentation during playback, and a description of the effects of changing attributes during playback.

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.

• SMIL 3.0 Content Control
• SMIL 3.0 Layout
• SMIL 3.0 Linking
• SMIL 3.0 Media Object
• SMIL 3.0 Modularization and conformance criteria
• SMIL 3.0 Metainformation
• SMIL 3.0 Timing and Synchronization

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.

• SMIL 3.0 Animation
• SMIL 3.0 Structure
• SMIL 3.0 Time Manipulations
• SMIL 3.0 Transition effects

1.4.2 Profiles affected by SMIL 3.0

1- New SMIL 3.0 Profiles:

SMIL3.0 adds the following two new Profiles:

• SMIL 3.0 Daisy Profile is a collection of SMIL 3.0 modules introduced for DAISY books. These digital talking books are fully accessible for persons with print disabilities, including blindness, low-vision, and dyslexia.
• SMIL 3.0 Tiny Profile is the minimum collection of SMIL 3.0 modules that provide support for the SMIL 3.0 language.
  This profile is suitable for systems which require very simple SMIL presentations where user interactions and specific content layout are not necessary. This is, for instance, the case of devices with reduced computing capabilities such as MP3/MP4 players, minimum capability mobile phones, car navigation systems, television sets or voice user agents. Also, it is possible to use the profile in the development of server side playlists. These playlists are used to generate continuous streams from individual video or audio files. The server processes the playlists without any user interaction.

2- Updated SMIL 3.0 Profiles:

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

• SMIL 3.0 Language Profile describes the SMIL 3.0 modules that are included in the SMIL 3.0 Language and details how these modules are integrated. It contains support for all of the major SMIL 3.0 features including animation, content control, layout, linking, media object, meta-information, structure, timing and transition effects. It is designed for Web clients that support direct playback from SMIL 3.0 markup.

3- Unchanged SMIL 3.0 Profiles:

The following Profiles are unchanged from SMIL 2.1 [SMIL21].

• SMIL 3.0 Extented Mobile Profile is a collection of SMIL 3.0 modules that provide extensive support for the SMIL 3.0 Language within the context of an advanced mobile device. Such a device is expected to have a high-resolution display and sufficient memory and processor capacity to render nontrival SMIL documents. Although not as complete as the full SMIL 3.0 Language Profile, the SMIL 3.0 Extended Mobile Profile is rich enough to meet the needs of a wide range of interactive presentations.
• SMIL 3.0 Mobile Profile provides support for the SMIL 3.0 language within the context of a mobile device. Such a device is expected to have sufficient display, memory, and processor capabilities to render basic interactive multimedia presentations in SMIL. The SMIL 3.0 Mobile Profile is a sub-set of the SMIL 3.0 Extended Mobile Profile. The SMIL 3.0 Mobile Profile is largely compatibility with the SMIL profile that third Generation Partnership Program (3GPP) has defined for the multimedia messaging (MMS) and the enhanced packed switched streaming (e-PSS) mobile services in its own specification ([3GPP26.246R6]).

Finally, SMIL 3.0 provides a Scalability Framework, where a family of scalable SMIL profiles can be defined using a sub- or superset of the SMIL 3.0 Language, Daisy, Mobile, or Extended Mobile profiles, or a superset of the SMIL 3.0 Tiny profile.

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

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. This coherency is expressed in that the elements of these modules are associated with the same namespace.

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

Commonly, there is a main language profile that incorporates nearly all the modules associated with a single namespace. For example, the SMIL 3.0 Language Profile uses most of the SMIL 3.0 modules. Usually, the same name is used to loosely reference both - "SMIL 3.0" in the example. Also, the name "profile" is used to mean "language profile".

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

A special module in a language profile is the so-called Structure Module, in that it contains the root element of the language profile, e.g. <smil> or <html>. Any language profile that incorporates modules associated with a single namespace will include the Structure module associated with that namespace.

Other modules that require special mention are those that characterize the core of the functionality provided by the namespace. 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 language 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 language 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 language profile to be used for the document interchange.

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, BasicText, TextStyling, TextMotion modules and StateTest, UserState, StateSubmission, StateInterpolation modules, StructureLayout and Timesheets 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

• The new chapter SMIL 3.0 DOM describes how the DOM can be used in SMIL 3.0.

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.

• The RequiredContentControl, defining the systemRequired attribute to specify the namespace prefixes of modules required to process a particular SMIL file.

Layout

SMIL 3.0 extends the Layout capabilities as follows:

• The BasicLayout module is extended with the backgroundOpacity attribute, which specifies the background opacity of a region;
• A new StructureLayout module defines the layout element, to indentify the layout mechanism used by a SMIL profile independently of the SMIL basic layout architecture.

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

• Introduction of the new MediaPanZoom module for panning and zooming over media content;
• The former MediaParam module is extended with new attributes and split into MediaParam module and MediaRenderAttributes module.

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:

• Introduction of the new BasicText module provides basic support for in-line text within a SMIL presentation;
• The new TextStyling adds styling capabilities of text;
• The new TextMotion module defines how text is added.

Metainformation

• The Metainformation module is extended as follows :
  - allowing meta-information to be placed on elements within the body instead of only in the head element.
  - the label attribute is added so that extended content information can be provided for document components.
  - the text in this section makes it clear that several different types of metainformation encodings may be used within a single presentation.

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:

• The new module, DOMTimingMethods adds DOM methods;
• Revision of allowed values for the begin attribute of children of a seq container to simplify implementations by removing the need for special case code.

External Timing

This functional area defines an XML timing language that makes SMIL 3.0 element and attribute timing control available to a wide range of other XML languages. It allows SMIL timing to be integrated in to a wide variety of a-temporal languages, even when several such languages are combined in a compound document. Because of its similarity with external style and positioning descriptions in the cascading style sheet language CSS, this functionality has been termed SMIL timesheets.

• The new Timesheets module provides basic support for timesheets mark-up for XML.

State

The new modules in this section provide a mechanism whereby the document author can 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:

• Introduction of the new StateTest module, containing extended content selection;
• The new UserState module, containing author-defined state;
• The new StateSubmission module, saving author-defined state;
• The new StateInterpolation module, allowing runtime modification to attribute values.

This section is informative.

This section is informative.

In this section we specify the rules for SMIL host language and SMIL integration set conformance. First, the conformance requirements for host language conformance and integration set conformance are given. The requirements are similar to those set forth for XHTML host language document type conformance and XHTML integration set document type conformance [XMOD]. In a final section the requirements on identifiers for host language conformant language profiles are given.

Currently, there exist five language profiles using SMIL 3.0 Modules. They are the SMIL 3.0 Language Profile, the SMIL 3.0 Extended Mobile Profile, the SMIL 3.0 Mobile Profile, the SMIL 3.0 Daisy Profile, the SMIL 3.0 Tiny profile. All five profiles are SMIL host language conformant.

SMIL 3.0 provides a scalability framework, where a family of scalable SMIL profiles can be defined using a sub- or superset of the SMIL 3.0 Language, Daisy, Mobile, or Extended Mobile profiles, or a superset of the SMIL 3.0 Tiny profile.

This section is informative.

A language profile is specified through its DTD or XML Schema. The identifier of these can be used to identify the language profile. SMIL 1.0 has specified the default namespace declaration on its root element, smil, as the decisive identifier for distinguishing it from other language profiles [SMIL10]. For that purpose SMIL 1.0 has specified

http://www.w3.org/TR/REC-smil

as the namespace identifier for SMIL 1.0

This section is informative.

This section describes how language 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 can 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 language 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 language 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 can 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 files that are different for each profile are the driver file and document model file. This would, in general, also apply to new profiles: to define a new language 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. 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 which document model file and which of the SMIL module files the profile is using. It may also define an optional namespace to be used in all namespace prefixes. For example, to prefix all SMIL element names with "foobar", the following can be added to the start of the profile:

<!ENTITY % SMIL.prefixed "INCLUDE" >
<!ENTITY % SMIL.prefix "foobar" >

Elements defined in their modules as, for example, <video> will become parsed as <foobar:video>. This also applies for SMIL attributes that appear on other elements, so, for example, "begin" becomes "foobar:begin". The default is that the qname prefix is empty -- that is, it is effectively turned off by default.

After these definitions, the driver file includes the framework file (which will subsequently include the data type, common attributes, qname and document model file), after which the SMIL module files are included that are used by this profile.

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 need to 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 need to 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/2007/07/SMIL30/SMIL30.dtd
-//W3C//DTD SMIL 3.0 Extended Mobile//EN	http://www.w3.org/2007/07/SMIL30/SMIL30ExtendedMobile.dtd
-//W3C//DTD SMIL 3.0 Mobile//EN	http://www.w3.org/2007/07/SMIL30/SMIL30Mobile.dtd
-//W3C//DTD SMIL 3.0 Daisy//EN	http://www.w3.org/2007/07/SMIL30/SMIL30Daisy.dtd
-//W3C//DTD SMIL 3.0 Tiny//EN	http://www.w3.org/2007/07/SMIL30/SMIL30Tiny.dtd

Document model files for the predefined profiles
-//W3C//ENTITIES SMIL 3.0 Language Profile Document Model 1.0//EN	http://www.w3.org/2007/07/SMIL30/smil-language-profile-model-1.mod
-//W3C//ENTITIES SMIL 3.0 Extended Mobile Profile Document Model 1.0//EN	http://www.w3.org/2007/07/SMIL30/smil-extended-mobile-profile-model-1.mod
-//W3C//ENTITIES SMIL 3.0 Mobile Profile Document Model 1.0//EN	http://www.w3.org/2007/07/SMIL30/smil-mobile-profile-model-1.mod
-//W3C//ENTITIES SMIL 3.0 Daisy Profile Document Model 1.0//EN	http://www.w3.org/2007/07/SMIL30/smil-daisy-profile-model-1.mod
-//W3C//ENTITIES SMIL 3.0 Tiny Profile Document Model 1.0//EN	http://www.w3.org/2007/07/SMIL30/smil-tiny-profile-model-1.mod

SMIL 3.0 module files
-//W3C//ELEMENTS SMIL 3.0 Animation//EN	http://www.w3.org/2007/07/SMIL30/SMIL-anim.mod
-//W3C//ELEMENTS SMIL 3.0 Content Control//EN	http://www.w3.org/2007/07/SMIL30/SMIL-control.mod
-//W3C//ELEMENTS SMIL 3.0 Layout//EN	http://www.w3.org/2007/07/SMIL30/SMIL-layout.mod
-//W3C//ELEMENTS SMIL 3.0 Linking//EN	http://www.w3.org/2007/07/SMIL30/SMIL-link.mod
-//W3C//ELEMENTS SMIL 3.0 Media Objects//EN	http://www.w3.org/2007/07/SMIL30/SMIL-media.mod
-//W3C//ELEMENTS SMIL 3.0 SMIL Text//EN	http://www.w3.org/2007/07/SMIL30/SMIL-text.mod
-//W3C//ELEMENTS SMIL 3.0 Document Metainformation//EN	http://www.w3.org/2007/07/SMIL30/SMIL-metainformation.mod
-//W3C//ELEMENTS SMIL 3.0 Document Structure//EN	http://www.w3.org/2007/07/SMIL30/SMIL-struct.mod
-//W3C//ELEMENTS SMIL 3.0 Timing//EN	http://www.w3.org/2007/07/SMIL30/SMIL-timing.mod
-//W3C//ELEMENTS SMIL 3.0 External Timing//EN	http://www.w3.org/2007/07/SMIL30/SMIL-external-timing.mod
-//W3C//ELEMENTS SMIL 3.0 State//EN	http://www.w3.org/2007/07/SMIL30/SMIL-state.mod
-//W3C//ELEMENTS SMIL 3.0 Transition//EN	http://www.w3.org/2007/07/SMIL30/SMIL-transition.mod

Other utilities: data types, common attributes, qname and frame work files
-//W3C//ENTITIES SMIL 3.0 Datatypes 1.0//EN	http://www.w3.org/2007/07/SMIL30/smil-datatypes-1.mod
-//W3C//ENTITIES SMIL 3.0 Common Attributes 1.0//EN	http://www.w3.org/2007/07/SMIL30/smil-attribs-1.mod
-//W3C//ENTITIES SMIL 3.0 Qualified Names 1.0//EN	http://www.w3.org/2007/07/SMIL30/smil-qname-1.mod
-//W3C//ENTITIES SMIL 3.0 Modular Framework 1.0//EN	http://www.w3.org/2007/07/SMIL30/smil-framework-1.mod

This section is informative.

The SMIL 3.0 specification leaves the SMIL 2.1 Animation Modules [SMIL21-animation] mostly unchanged. The only changes are that normative text is added that clarifies the ability of a host language designer to override the event base default element, and that several typos and some examples have been corrected.

This section is informative.

This section defines the SMIL 3.0 Animation Modules, which are composed of a BasicAnimation module and a SplineAnimation module. These modules contain elements and attributes for incorporating animation onto a time line, and a mechanism for composing the effects of multiple animations. Since these elements and attributes are defined in modules, designers of other markup languages can choose whether or not to include this functionality in their languages. Language designers incorporating other SMIL modules do not need to include the animation modules if animation functionality is not needed.

The examples in this document that include syntax for a host language use [SMIL10], [SVG], [HTML4] and [CSS2]. These are provided as an indication of possible integrations with various host languages.

While this document defines a base set of animation capabilities, it is assumed that host languages may build upon the support to define additional or more specialized animation elements. Animation only manipulates attributes and properties of the target elements, and so does not require any knowledge of the target element semantics beyond basic type information.

This module depends on the SMIL 3.0 BasicInlineTiming module, using elements and attributes from the Timing module for its time line. The BasicInlineTiming module is a prerequisite for any profile using SMIL Animation. The reader is presumed to have read and be familiar with the SMIL 3.0 Timing modules.

This section first presents the underlying principals of animation in SMIL 3.0, then the elements and attributes of the BasicAnimation module and of the SplineAnimation module.

This section is informative.

This section describes the semantics underlying the SMIL 3.0 animation modules. The specific elements are not described here, but rather the common concepts and syntax that comprise the model for animation. Document issues are described, as well as the means to target an element for animation. The animation model is then defined by building up from the simplest to the most complex concepts: first the simple duration and simple animation function f(t), and then the overall effect F(t,u).

This section is informative.

As a simple example, the following defines an animation of an SVG rectangle shape. The rectangle will change from being tall and thin to being short and wide.

<rect ...>
   <animate attributeName="width"  from="10px"  to="100px" 
            begin="0s" dur="10s" />
   <animate attributeName="height" from="100px" to="10px"
            begin="0s" dur="10s" />
</rect>

The rectangle begins with a width of 10 pixels and increases to a width of 100 pixels over the course of 10 seconds. Over the same ten seconds, the height of the rectangle changes from 100 pixels to 10 pixels.

When an animation is running, it should not actually change the attribute values in the DOM [DOM2]. The animation runtime should maintain a presentation value for each animated attribute, separate from the DOM or CSS Object Model (OM). If an implementation does not support an object model, it should maintain the original value as defined by the document as well as the presentation value. The presentation value is reflected in the displayed form of the document. Animations thus manipulate the presentation value, and should not affect the base value exposed by DOM or CSS OM. This is detailed in The animation sandwich model.

In the example immediately above, the simple animation function for the width attribute, specified by 'from="10px" to="100px" ... dur="10s"' is

f(t) = (10 + 90*t/10) px, where t is given in seconds.

This section is informative.

a

The target attribute of an animation element.

d

The simple duration of the element.

AD

The active duration of the element.

t

A time. Depending on the context, t may be in user-perceived time, an element's active duration, or its simple duration.

u

The underlying value of the target attribute a, generally at a specific time t.

f(t)

The simple animation function of times within the simple duration. This is defined for t: 0<=t<d.

Note that while F(t,u) defines the mapping for the entire animation, f(t) has a simplified model that just handles the simple duration.

f(d)

While f(t) is not defined for the value t=d, the expression f(d) is used as a shorthand to refer to the last value defined for the animation function.

F(t,u)

The effect of an animation for any point in the active duration of the animation. This maps times within the active duration (t: 0<=t<AD) and an underlying value to a value for the target attribute. A time value of 0 corresponds to the time at which the animation begins. F(t,u) combines the simple animation function f(t) with all the other aspects of animation and timing controls.

This section is informative.

When an animation is running, it does not actually change the attribute values in the DOM. The animation runtime should ideally maintain a presentation value for any target attribute, separate from the DOM, CSS, or other object model (OM) in which the target attribute is defined. The presentation value is reflected in the display form of the document. The effect of animations is to manipulate this presentation value, and not to affect the underlying DOM or CSS OM values.

The remainder of this discussion uses the generic term OM for both the XML DOM [DOM2] as well as the CSS-OM. If an implementation does not support an object model, it should ideally maintain the original value as defined by the document as well as the presentation value; for the purposes of this section, we will consider this original value to be equivalent to the value in the OM.

In some implementations of DOM, it may be difficult or impractical to maintain a presentation value as described. CSS values should always be supported as described, as the CSS-OM provides a mechanism to do so. In implementations that do not support separate presentation values for general XML DOM properties, the implementation must at least restore the original value when animations no longer have an effect.

The rest of this discussion assumes the recommended approach using a separate presentation value.

The model accounting for the OM and concurrently active or frozen animations for a given attribute is described as a "sandwich", a loose analogy to the layers of meat and cheeses in a "submarine sandwich" (a long sandwich made with many pieces of meats and cheese layered along the length of the bread). In the analogy, time is associated with the length of the sandwich, and each animation has its duration represented by the length of bread that the layer covers. On the bottom of the sandwich is the base value taken from the OM. Each active (or frozen) animation is a layer above this. The layers (i.e. the animations) are placed on the sandwich both in time along the length of the bread, as well as in order according to priority, with higher priority animations placed above (i.e. on top of) lower priority animations. At any given point in time, you can take a slice of the sandwich and see how the animation layers stack up.

Note that animations manipulate the presentation value coming out of the OM in which the attribute is defined, and pass the resulting value on to the next layer of document processing. This does not replace or override any of the normal document OM processing cascade.

Specifically, animating an attribute defined in XML will modify the presentation value before it is passed through the style sheet cascade, using the XML DOM value as its base. Animating an attribute defined in a style sheet language will modify the presentation value passed through the remainder of the cascade.

In CSS2 and the DOM 2 CSS-OM, the terms "specified", "computed" and "actual" are used to describe the results of evaluating the syntax, the cascade and the presentation rendering. When animation is applied to CSS properties of a particular element, the base value to be animated is read using the (readonly) getComputedStyle() method on that element. The values produced by the animation are written into an override stylesheet for that element, which may be obtained using the getOverrideStyle() method. Note that it is assumed that before reading the value, the override stylesheet is cleared so that the animation works on the original document value. These new values then affect the cascade and are reflected in a new computed value (and thus, modified presentation). This means that the effect of animation overrides all style sheet rules, except for user rules with the !important property. This enables !important user style settings to have priority over animations, an important requirement for accessibility. Note that the animation may have side effects upon the document layout. See also section 6.1, "Specified, computed, and actual values," of [CSS2] and section 5.2.1, "Override and computed style sheet," of [DOM2CSS].

Within an OM, animations are prioritized according to when each begins. The animation first begun has lowest priority and the most recently begun animation has highest priority. When two animations start at the same moment in time, the activation order is resolved as follows:

• If one animation is a time dependent of another (e.g. it is specified to begin when another begins), then the time dependent is considered to activate after the syncbase element, and so has higher priority. Time dependency is further discussed in Propagating changes to times. This rule applies independent of the timing described for the syncbase element - i.e. it does not matter whether the syncbase element begins on an offset, relative to another syncbase, relative to an event-base, or via hyperlinking. In all cases, the syncbase is begun before any time dependents are begun, and so the syncbase has lower priority than the time dependent.
• If two animations share no time dependency relationship (e.g. neither is defined relative to the other, even indirectly) the element that appears first in the document has lower priority. This includes the cases in which two animation elements are defined relative to the same syncbase or event-base.

Note that if an animation is restarted (see also Restarting animations), it will always move to the top of the priority list, as it becomes the most recently activated animation. That is, when an animation restarts, its layer is pulled out of the sandwich, and added back on the very top. In contrast, when an element repeats the priority is not affected (repeat behavior is not defined as restarting).

Each additive animation adds its effect to the result of all sandwich layers below. A non-additive animation simply overrides the result of all lower sandwich layers. The end result at the top of the sandwich is the presentation value that must be reflected in the document view.

Some attributes that support additive animation have a defined legal range for values (e.g. an opacity attribute may allow values between 0 and 1). In some cases, an animation function may yield out of range values. It is recommended that implementations clamp the results to the legal range as late as possible, before applying them to the presentation value. Ideally, the effect of all the animations active or frozen at a given point should be combined, before any clamping is performed. Although individual animation functions may yield out of range values, the combination of additive animations may still be legal. Clamping only the final result and not the effect of the individual animation functions provides support for these cases. Intermediate results may be clamped when necessary although this is not optimal. The host language must define the clamping semantics for each attribute that can be animated. As an example, this is defined for animateColor element.

Initially, before any animations for a given attribute are active, the presentation value will be identical to the original value specified in the document (the OM value).

When all animations for a given attribute have completed and the associated animation effects are no longer applied, the presentation value will again be equal to the OM value. Note that if any animation is defined with fill="freeze", the effect of the animation will be applied as long as the animation element remains in the frozen state, and so the presentation value will continue to reflect the animation effect. Refer also to the section "Freezing animations".

Some animations (e.g. animateMotion) will implicitly target an attribute, or possibly several attributes (e.g. the "posX" and "posY" attributes of some layout model). These animations must be combined with any other animations for each attribute that is affected. Thus, e.g. an animateMotion animation may be in more than one animation sandwich (depending upon the layout model of the host language). For animation elements that implicitly target attributes, the host language designer must specify which attributes are implicitly targeted, and the runtime must accordingly combine animations for the respective attributes.

Note that any queries (via DOM interfaces) on the target attribute will reflect the OM value, and will not reflect the effect of animations. Note also that the OM value may still be changed via the OM interfaces (e.g. using script). While it may be useful or desired to provide access to the final presentation value after all animation effects have been applied, such an interface is not provided as part of SMIL Animation. A future version may address this.

Although animation does not manipulate the OM values, the document display must reflect changes to the OM values. Host languages can support script languages that can manipulate attribute values directly in the OM. If an animation is active or frozen while a change to the OM value is made, the behavior is dependent upon whether the animation is defined to be additive or not, as follows: (see also the section Additive animation).

• If only additive animations are active or frozen (i.e. no non-additive animations are active or frozen for the given attribute) when the OM value is changed, the presentation value must reflect the changed OM value as well as the effect of the additive animations. When the animations complete and the effect of each is no longer applied, the presentation value will be equal to the changed OM value.
  
• If any non-additive animation is running when the OM value is changed, the presentation value will not reflect the changed OM value, but will only reflect the effect of the highest priority non-additive animation, and any still higher priority additive animations. When all non-additive animations complete and the effect of each is no longer applied, the presentation value will reflect the changed OM value and the effect of any additive animations that are active or frozen.

This section is informative.

Within the timing model, animation is considered to be "continuous" media. The animation elements defined in SMIL Animation do not have a natural intrinsic duration, so they are assigned an intrinsic duration of indefinite.

This has several consequences, which are noted in various sections below. In particular, most animation elements will have an explicit duration set with the dur attribute, since a finite, known duration is required for interpolation.

This section is informative.

As described above, the simple animation function f(t) defines the animation for the simple duration d. However, SMIL Timing allows the author to repeat the simple duration. SMIL Timing also allows authors to specify whether the animation should simply end when the active duration completes, or whether it should be frozen at the last value. SMIL Animation specifies what it means for an animation to be frozen. In addition, the author can specify how each animation should be combined with other animations and the original DOM value.

This section describes the semantics for the additional functionality, including a detailed model for combining animations. This is presented as a sequence of functions building on the simple animation function:

• The repeated animation function, fr(t), defines the effect of repeating an animation element.
• The cumulative animation function, fc(t), defines the effect of accumulating values from one iteration to the next of a repeated animation element.
• The frozen animation function, ff(t), includes the effect of freezing an animation element at the end of its active duration.
• The animation effect function, F(t,u), defines how a an animation element depends on the underlying value u of the target attribute.

Since these functions describe the animation outside of the simple duration, they are defined for any time t: 0<=t<AD . The frozen animation function ff(t),is additionally defined for t=AD, to account for the case when the element is frozen.

Examples

This section is informative.

In the following example, the 2.5 second animation function will be repeated twice; the active duration will be 5 seconds. The attribute top will go from 0 to (almost) 10, return to 0 at 2.5 seconds, and repeat.

<animate attributeName="top" from="0" to="10" dur="2.5s"
repeatCount="2" />

In the following example, the animation function will be repeated two full times and then the first half is repeated once more; the active duration will be 7.5 seconds.

<animate attributeName="top" from="0" to="10" dur="3s"
repeatCount="2.5" />

In the following example, the animation function 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. The last (partial) iteration will apply values in the range "0" to "8".

<animate attributeName="top" from="0" to="10" dur="2.5s"
repeatDur="7s" />

In the following example, the simple duration is longer than the duration specified by repeatDur, and so the active duration will effectively cut short the simple duration. However, the animation function still uses the specified simple duration. The effect of the animation is to interpolate the value of "top" from 10 to 15, over the course of 5 seconds.

<animate attributeName="top" from="10" to="20"
dur="10s" repeatDur="5s" />

Note that if the simple duration is not defined (e.g. it is indefinite), repeat behavior is not defined (but repeatDur still defines the active duration). In the following example the simple duration is indefinite, and so the repeatCount is effectively ignored. Nevertheless, this is not considered an error: the active duration is also indefinite. The effect of the animation is to to just use the value for f(0), setting the fill color to red for the remainder of the animate element's duration.

<animate attributeName="fill" from="red" to="blue" repeatCount="2" />

In the following example, the simple duration is indefinite, but the repeatDur still determines the active duration. The effect of the animation is to set the fill color to red for 10 seconds.

<animate attributeName="fill" from="red" to="blue" repeatDur="10s" />

In the following example, the simple duration is longer than the duration specified by repeatDur, and so the active duration will effectively cut short the simple duration. However, the animation function still interpolates using the specified simple duration. The effect of the animation is to interpolate the value of "top" from 10 to 17, over the course of 7 seconds.

<animate attributeName="top" from="10" to="20"
dur="10s" repeatDur="7s" />

This section is informative.

Note that fi+1(t)starts at f(d)*i + f(0). To avoid jumps, authors will typically choose animation functions which start at 0.

For example, the path notation for a simple arc (detailed in The animateMotion element) can be used to describe a bouncing motion:

<img ...>
   <animateMotion path="m 0 0 c 30 50 70 50 100 0 z" dur="5s"
      accumulate="sum" repeatCount="4" />
</img>

The image moves from the original position along the arc over the course of 5 seconds. As the animation repeats, it builds upon the previous value and begins the second arc where the first one ended, as illustrated in Figure 1, below. In this way, the image "bounces" across the screen. The same animation could be described as a complete path of 4 arcs, but in the general case the path description can get quite large and cumbersome to edit.

Figure 1 - Illustration of repeating animation with accumulate="sum".

Figure 1 - A cumulative repeating animation. Each repeat iteration builds upon the previous.

Note that cumulative animation only controls how a single animation accumulates the results of the simple animation function as it repeats. It specifically does not control how one animation interacts with other animations to produce a presentation value. This latter behavior is described in the section Additive animation. Similarly, if an element restarts, the accumulate from the first run is not applied to the second. See Restarting animations.

Any numeric attribute that supports addition can support cumulative animation. For example, we can define a "pulsing" animation that will grow the "width" of an SVG <rect> element by 100 pixels in 50 seconds.

<rect width="20px"...>
   <animate attributeName="width" dur="5s"
      values="0; 15; 10" additive="sum"
      accumulate="sum" repeatCount="10" />
</rect>

Each simple duration causes the rectangle width to bulge by 15 pixels and end up 10 pixels larger. The shape is 20 pixels wide at the beginning, and after 5 seconds is 30 pixels wide. The animation repeats, and builds upon the previous values. The shape will bulge to 45 pixels and then end up 40 pixels wide after 10 seconds, and will eventually end up 120 (20 + 100) pixels wide after all 10 repeats.

Freezing animations

Animation elements follow the definition of fill in the Timing module. This section extends that specification to cover animation-specific semantics.

By default when an animation element ends, its effect is no longer applied to the presentation value for the target attribute. For example, if an animation moves an image and the animation element ends, the image will "jump back" to its original position.

<img top="3" ...>
   <animate begin="5s" dur="10s" attributeName="top" by="100"/>
</img>

As shown in Figure 2, the image will appear stationary at the top value of "3" for 5 seconds, then move 100 pixels down in 10 seconds. 15 seconds after the document begin, the animation ends, the effect is no longer applied, and the image jumps back from 103 to 3 where it started (i.e. to the underlying DOM value of the top attribute).

Figure 2 - Illustration of animation without freezing.

Figure 2 - Simple animation without freezing. After the animate element ends, the effect of the animation is removed.

The fill attribute can be used to maintain the value of the animation after the active duration of the animation element ends:

<img top="3" ...>
   <animate begin= "5s" dur="10s" attributeName="top" by="100"
          fill="freeze" />
</img>

The animation ends 15 seconds after the document begin, but the image remains at the top value of 103 (Figure 3). The attribute freezes the last value of the animation for the duration of the freeze effect. This duration is controlled by the time container (for details, see SMIL Timing and Synchronization).

Figure 3 - Illustration of animation with fill="freeze".

Figure 3 - Simple frozen animation. After the animate element ends, the effect of the animation is retained.

If the active duration cuts short the simple duration (including the case of partial repeats), the effect value of a frozen animation is defined by the shortened simple duration. In the following example, the simple animation function repeats two full times and then again for one-half of the simple duration. In this case, the value while frozen will be 53:

<img top="3" ...>
   <animate begin= "5s" dur="10s" attributeName="top" by="100"
          repeatCount="2.5" fill="freeze" />
</img>

Figure 4 - Illustration of animation combining a partial repeat and fill="freeze".

In the following example, the dur attribute is missing, and so the simple duration is indefinite. The active duration is constrained by end to be 10 seconds. Interpolation is not defined, and the value while frozen will be the from value, 10:

<animate from="10" to="20" end="10s" fill="freeze" .../> 

This section is informative.

In addition to repeating and accumulating values of a single animation, an animation may be expressed as a delta to an attribute's value, rather than as an absolute value. This can be used in a single animation to modify the underlying DOM value, or complex animations can be produced by combining several simple ones.

For example, a simple "grow" animation can increase the width of an object by 10 pixels:

<rect width="20px" ...>
   <animate attributeName="width" from="0px" to="10px" dur="10s"
      additive="sum"/>
</rect>

The width begins at 20 pixels, and increases to 30 pixels over the course of 10 seconds. If the animation were declared to be non-additive, the same from and to values would make the width go from 0 to 10 pixels over 10 seconds.

Many complex animations are best expressed as combinations of simpler animations. A "vibrating" path, for example, can be described as a repeating up and down motion added to any other motion:

<img ...>
   <animateMotion from="0,0" to="100,0" dur="10s" />
   <animateMotion values="0,0; 0,5; 0,0" dur="1s"
                  repeatDur="10s" additive="sum"/>
</img>

This section is informative.

When there are multiple animations defined for a given attribute that overlap at any moment, the two either add together or one overrides the other. Animations overlap when they are both either active or frozen at the same moment. The ordering of animations (e.g. which animation overrides which) is determined by a priority associated with each animation. The animations are prioritized according to when each begins. The animation first begun has lowest priority and the most recently begun animation has highest priority.

Higher priority animations that are not additive will override all earlier (lower priority) animations, and simply set the attribute value. Animations that are additive apply (i.e. add to) to the result of the earlier-activated animations. For details on how animations are combined, see The animation sandwich model.

Additive animation is defined for numeric attributes and other data types for which an addition function is defined. This includes numeric attributes for concepts such as position, widths and heights, sizes, etc. This also includes color (refer to The animateColor element), and may include other data types as specified by the host language.

It is often useful to combine additive animations and fill behavior, for example when a series of motions are defined that should build upon one another:

<img ...>
   <animateMotion begin="0" dur="5s" path="[some path]"
           additive="sum" fill="freeze" />
   <animateMotion begin="5s" dur="5s" path="[some path]"
           additive="sum" fill="freeze" />
   <animateMotion begin="10s" dur="5s" path="[some path]"
           additive="sum" fill="freeze" />
</img>

The image moves along the first path, and then starts the second path from the end of the first, then follows the third path from the end of the second, and stays at the final point.

While many animations of numerical attributes will be additive, this is not always the case. As an example of an animation that is defined to be non-additive, consider a hypothetical extension animation "mouseFollow" that causes an object to track the mouse.

<img ...>
   <animateMotion dur="10s" repeatDur="indefinite"
           path="[some nice path]" />
   <mouseFollow begin="mouseover" dur="5s"
           additive="replace" fill="remove" />
</img>

The mouse-tracking animation runs for 5 seconds every time the user mouses over the image. It cannot be additive, or it will just offset the motion path in some odd way. The mouseFollow needs to override the animateMotion while it is active. When the mouseFollow completes, its effect is no longer applied and the animateMotion again controls the presentation value for position.

In addition, some numeric attributes (e.g. a telephone number attribute) may not sensibly support addition. It is left to the host language to specify which attributes support additive animation. Attribute types for which addition is not defined, such as strings and Booleans, cannot support additive animation.

Additive and Cumulative animation

The accumulate attribute should not be confused with the additive attribute. The additive attribute defines how an animation is combined with other animations and the base value of the attribute. The accumulate attribute defines only how the simple animation function interacts with itself, across repeat iterations.

Typically, authors expect cumulative animations to be additive (as in the examples described for accumulate above), but this is not required. The following example is cumulative but not additive.

<img ...>
   <animate dur="10s" repeatDur="indefinite"
            attributeName="top" from="20" by="10"
            additive="replace" accumulate="sum" />
</img>

The animation overrides whatever original value was set for "top", and begins at the value 20. It moves down by 10 pixels to 30, then repeats. It is cumulative, so the second iteration starts at 50 (the value of 30 from the previous iteration plus the from value, 20) and moves down by another 10 to 60, and so on.

When a cumulative animation is also defined to be additive, the two features function normally. The accumulated effect for F(t,u) is used as the value for the animation, and is added to the underlying value for the target attribute. For example:

<img top="10" ... >
  <animate dur="10s" repeatDur="indefinite"

           attributename="top" from="20" by="10"

           additive="sum" accumulate="sum" />
</img>

The animation adds to the original value of 10 that was set for "top", and begins at the value 30. It moves down by 10 pixels to 40, then repeats. It is cumulative, so the second iteration starts at 60 (the value of 40 from the previous iteration plus 20) and moves down by another 10 to 70, and so on.

Refer also to The animation sandwich model.

This section is informative.

Animation elements follow the definition of restart in the SMIL Timing module. This section is descriptive.

When an animation restarts, the defining semantic is that it behaves as though this were the first time the animation had begun, independent of any earlier behavior. The animation effect function F(t,u) is defined independent of the restart behavior. Any effect of an animation playing earlier is no longer applied, and only the current animation effect F(t,u) is applied.

If an additive animation is restarted while it is active or frozen, the previous effect of the animation (i.e. before the restart) is no longer applied to the attribute. Note in particular that cumulative animation is defined only within the active duration of an animation. When an animation restarts, all accumulated context is discarded, and the animation effect F(t,u) begins accumulating again from the first iteration of the restarted active duration.

Many animations specify the simple animation function f(t) as a sequence of values to be applied over time. For some types of attributes (e.g. numbers), it is also possible to describe an interpolation function between values.

As a simple form of describing the values, animation elements can specify a from value and a to value. If the attribute takes values that support interpolation (e.g. a number), the simple animation function can interpolate values in the range defined by from and to, over the course of the simple duration. A variant on this uses a by value in place of the to value, to indicate an additive change to the attribute.

More complex forms specify a list of values, or even a path description for motion. Authors can also control the timing of the values, to describe "keyframe" animations, and even more complex functions.

In all cases, the animation effect function, F(t,u), must yield legal values for the target attribute. Three classes of values are described:

1. Unitless scalar values. These are simple scalar values that can be parsed and set without semantic constraints. This class includes integers (base 10) and floating point (format specified by the host language).
2. String values. These are simple strings.
3. Language abstract values. These are values like CSS-length and CSS-angle values that have more complex parsing, but that can yield values that may be interpolated.

The animate element can interpolate unitless scalar values, and both animate and set elements can handle String values without any semantic knowledge of the target element or attribute. The animate and set elements must support unitless scalar values and string values. The host language must define which additional language abstract values should be handled by these elements. Note that the animateColor element implicitly handles the abstract values for color values, and that the animateMotion element implicitly handles position and path values.

In order to support interpolation on attributes that define numeric values with some sort of units or qualifiers (e.g. "10px", "2.3feet", "$2.99"), some additional support is required to parse and interpolate these values. One possibility is to require that the animation framework have built-in knowledge of the unit-qualified value types. However, this violates the principle of encapsulation and does not scale beyond CSS to XML languages that define new attribute value types of this form.

The recommended approach is for the animation implementation for a given host environment to support two interfaces that abstract the handling of the language abstract values. These interfaces are not formally specified, but are simply described as follows:

1. The first interface converts a string (the animation function value) to a unitless, canonical number (either an integer or a floating point value). This allows animation elements to interpolate between values without requiring specific knowledge of data types like CSS-length. The interface will likely require a reference to the target attribute, to determine the legal abstract values. If the passed string cannot be converted to a unitless scalar, the animation element will treat the animation function values as strings, and the calcMode will default to "discrete".
2. The second interface converts a unitless canonical number to a legal string value for the target attribute. This may, for example, simply convert the number to a string and append a suffix for the canonical units. The animation element uses the result of this to actually set the presentation value.

Support for these two interfaces ensures that an animation engine need not replicate the parser and any additional semantic logic associated with language abstract values.

This is not an attempt to specify how an implementation provides this support, but rather a requirement for how values are interpreted. Animation behaviors should not have to understand and be able to convert among all the CSS-length units, for example. In addition, this mechanism allows for application of animation to new XML languages, if the implementation for a language can provide parsing and conversion support for attribute values.

The above recommendations notwithstanding, it is sometimes useful to interpolate values in a specific unit-space, and to apply the result using the specified units rather than canonical units. This is especially true for certain relative units such as those defined by CSS (e.g. em units). If an animation specifies all the values in the same units, an implementation may use knowledge of the associated syntax to interpolate in the unit space, and apply the result within the animation sandwich, in terms of the specified units rather than canonical units. As noted above, this solution does not scale well to the general case. Nevertheless, in certain applications (such as CSS properties), it may be desirable to take this approach.

Interpolation and indefinite simple durations

If the simple duration of an animation is indefinite (e.g. if no dur value is specified), interpolation is not generally meaningful. While it is possible to define an animation function that is not based upon a defined simple duration (e.g. some random number algorithm), most animations define the function in terms of the simple duration. If an animation function is defined in terms of the simple duration and the simple duration is indefinite, the first value of the animation function (i.e. f(0)) should be used (effectively as a constant) for the animation function.

This section is informative.

The SMIL 3.0 BasicAnimation module provides

• Syntax for identifying target elements and attributes,
• Simple animation functions defined by sets of points to be visited in sequence, with the function defined between those using discrete, linear or paced interpolation.
• The animate element for generic animation.
• The set element for simply setting the value of the target attribute to a constant value
• The animateMotion element for defining motion on a path. And
• The animateColor element for defining color changes over time.

The BasicAnimation module defines attributes and elements following the model presented in the Animation Model section.

The elements of the BasicAnimation module have in common the attributes used to identify the target attribute and, less universally, the attributes by which the animation functions are specified.

<animate targetElement="foo" attributeName="bar" .../> 

<foo xmlns:xlink="http://www.w3.org/1999/xlink">
   ...
   <animate xlink:href="#foo" attributeName="bar" .../>
   ...
</foo>

This section is informative.

The following example using the values syntax animates the width of an SVG shape over the course of 10 seconds, interpolating from a width of 40 to a width of 100 and back to 40.

<rect ...>
   <animate attributeName="width" values="40;100;40" dur="10s"/>
</rect>

The simple animation function for this example (with time in seconds) is

f(t) = 40 + 60*t/5, 0 <= t < 5, and
f(t) = 100 - 60*(t-5)/5, 5 <= t <= 10.

Interpolation modes illustrated

This section is informative.

The three figures 5a, 5b and 5c below show how the same basic animation will change a value over time, given different interpolation modes. All examples are based upon the following example, but with different values for calcMode:

<animate dur="30s" values="0; 6; 5; 11; 10; 16" calcMode="[as specified]" />

Figure 5 - Discrete, linear and paced animation

	Figure 5a: Default discrete animation. calcMode="discrete" There are 6 segments of equal duration: 1 segment per value.
	Figure 5b: Default linear animation. calcMode="linear" There are 5 segments of equal duration: n-1 segments for n values.
	Figure 5c: Default paced animation. calcMode="paced" There are 5 segments of varying duration: n-1 segments for n values, computed to yield a constant rate of change in the value.

Examples of calcMode

The following example describes a simple discrete animation:

<animate attributeName="foo" dur="8s" 
     values="bar; fun; far; boo" />

The value of the attribute "foo" will be set to each of the four strings for 2 seconds each. Because the string values cannot be interpolated, only discrete animation is possible; any calcMode attribute would be ignored.

The following example describes a simple linear animation:

<animate attributeName="x" dur="10s" values="0; 10; 100" 
     calcMode="linear"/>

The value of "x" will change from 0 to 10 in the first 5 seconds, and then from 10 to 100 in the second 5 seconds. Note that the values in the values attribute are spaced evenly in time; in this case the result is a much larger actual change in the value during the second half of the animation. Contrast this with the same example changed to use "paced" interpolation:

<animate attributeName="x" dur="10s" values="0; 10; 100" 
     calcMode="paced"/>

To produce an even pace of change to the attribute "x", the second segment defined by the values list gets most of the simple duration: The value of "x" will change from 0 to 10 in the first second, and then from 10 to 100 in the next 9 seconds. While this example could be easily authored as a from-to animation without paced interpolation, many examples (such as motion paths) are much harder to author without the paced value for calcMode.

This section is informative.

Examples

The following "from-to animation" example animates the width of an SVG shape over the course of 10 seconds from a width of 50 to a width of 100.

<rect ...>
   <animate attributeName="width" from="50" to="100" dur="10s"/>
</rect>

The following "from-by animation" example animates the width of an SVG shape over the course of 10 seconds from a width of 50 to a width of 75.

<rect ...>
   <animate attributeName="width" from="50" by="25" dur="10s"/>
</rect>

The following "by animation" example animates the width of an SVG shape over the course of 10 seconds from the original width of 40 to a width of 70.

<rect width="40"...>
   <animate attributeName="width" by="30" dur="10s"/>
</rect>

From-to and from-by animations also support cumulative animation, as in the following example:

<rect width="20px"...>
   <animate attributeName="width" dur="5s" from="10px" to="20px"
      accumulate="sum" repeatCount="10" />
</rect>

The rectangle will grow from 10 to 20 pixels in the first 5 seconds, and then from 30 to 40 in the next 5 seconds, and so on up to 200 pixels after 10 repeats. Note that since the default value for additive is replace, the original value is ignored. The following example makes the animation explicitly additive:

<rect width="20px"...>
   <animate attributeName="width" dur="5s" from="10px" to="20px"
      accumulate="sum" additive="sum" repeatCount="10" />
</rect>

The results are the same as before, except that all the values are shifted up by the original value of 20. After 5 seconds, the rectangle jumps from 40 pixels to 50 pixels wide, and it is 220 pixels wide at the end of the 10th repeat.

A to animation of an attribute which supports addition is a kind of mix of additive and non-additive animation. The underlying value is used as a starting point as with additive animation, however the ending value specified by the to attribute overrides the underlying value as though the animation was non-additive.

The following "to animation" example animates the width of an SVG shape over the course of 10 seconds from the original width of 40 to a width of 100.

<rect width="40"...>
   <animate attributeName="width" to="100" dur="10s"/>
</rect>

Since a to animation has only 1 value, a discrete to animation will simply set the to value for the simple duration. In the following example, the rect will be blue for the 10 second duration of the animate element.

<rect color="red"...>
   <animate attributeName="color" to="blue" dur="10s" calcMode="discrete"/>
</rect>

The semantics of to animation fit into the general animation model, but with a few special cases. The normative definition given here parallels the definition for other types of animation presented in the Animation Model section.

<rect width="40"...>
   <animate attributeName="width" to="100" dur="10s" repeatCount="2.5" fill="freeze"/>
</rect>

This section is informative.

For an example of additive to animation, consider the following two additive animations. The first, a by-animation applies a delta to attribute "x" from 0 to -10. The second, a to animation animates to a final value of 10.

 <foo x="0" ...>
    <animate id="A1" attributeName="x" 
        by="-10" dur="10s" fill="freeze" />
    <animate id="A2" attributeName="x" 
        to="10"  dur="10s" fill="freeze" />
 </foo>

The presentation value for "x" in the example above, over the course of the 10 seconds is presented in Figure 6 below. These values are simply computed using the formula described above. Note that the value for F(t,u) for A2 is the presentation value for "x", since A2 is the higher-priority animation.

Figure 6 - Effect of Additive to animation example

Time	F(t,u) for A1	F(t,u) for A2
0	0	0
1	-1	0.1
2	-2	0.4
3	-3	0.9
4	-4	1.6
5	-5	2.5
6	-6	3.6
7	-7	4.9
8	-8	6.4
9	-9	8.1
10	-10	10

This section is informative.

Examples

The following changes the stroke-width of an SVG rectangle from the original value to 5 pixels wide. The effect begins at 5 seconds and lasts for 10 seconds, after which the original value is again used.

<rect ...>
   <set attributeName="stroke-width" to="5px" 
            begin="5s" dur="10s" fill="remove" />
</rect>

The following example sets the class attribute of the text element to the string "highlight" when the mouse moves over the element, and removes the effect when the mouse moves off the element.

<text>This will highlight if you mouse over it...
   <set attributeName="class" to="highlight" 
            begin="mouseover" end="mouseout" />
</text> 

coordinate-pair ::= "("coordinate comma-wsp coordinate")"
coordinate      ::= num
num             ::= Number

This section is informative.

Note that color values are corrected by clamping them to the gamut of the destination (display) colorspace. Some implementations may be unable to process values which are outside the source (sRGB) colorspace and must thus perform clamping to the source colorspace, then convert to the destination colorspace and clamp to its gamut. The point is to distinguish between the source and destination gamuts; to clamp as late as possible, and to realize that some devices, such as inkjet printers which appear to be RGB devices, have non-cubical gamuts.

Note to implementers: When animateColor is specified as a to animation, the animation function should assume Euclidean RGB-cube distance where deltas must be computed. See also Specifying the simple animation function f(t) and Simple animation functions specified by from, to and by. Similarly, when the calcMode attribute for animateColor is set to paced, the animation function should assume Euclidean RGB-cube distance to compute the distance and pacing.

This section is informative.

See the full DTD for the SMIL Animation Modules.

control-pt-set ::= ( fpval comma-wsp fpval comma-wsp fpval comma-wsp fpval )

fpval          ::= Floating point number
S              ::= spacechar*
comma-wsp      ::= S (spacechar|",") S
spacechar      ::= (#x20 | #x9 | #xD | #xA)

This section is informative.

Examples of advanced uses of calcMode

Discrete animation can be used with keyTimes, as in the following example:

<animateColor attributeName="color" dur="10s" calcMode="discrete"
     values="green; yellow; red" keyTimes="0.0; 0.5; 0.8" />

The value of the "color" attribute will be set to green for 5 seconds, and then to yellow for 3 seconds, and then will remain red for the remainder of the element.

When using discrete animation with a keyTimes value of 1, the result may be somewhat surprising. Consider the following example:

<par dur="30">
  <animate calcMode="discrete" repeatCount="2" dur="10" fill="freeze"
    accumulate="[as specified]" keyTimes="0.0; 0.5; 1.0" values="0; 1; 2"/>
</par>

This example is tricky because of the end-point-exclusive nature of the SMIL time model. At first flush, the final value is never reached since the final time is never reached, but the definitions above make that the value is used anyway. The table gives the value for selected times for the possible values of the accumulate attribute:

time	accumulate
	none	sum
t=0	0	0
t=5	1	1
t=10	0	2
t=15	1	3
t=20	2	4
t=25	2	4

The following example illustrates the use of keyTimes:

<animate attributeName="x" dur="10s" values="0; 50; 100" 
     keyTimes="0; .8; 1" calcMode="linear"/>

The keyTimes values cause the "x" attribute to have a value of "0" at the start of the animation, "50" after 8 seconds (at 80% into the simple duration) and "100" at the end of the animation. The value will change more slowly in the first half of the animation, and more quickly in the second half.

Interpolation with keySplines

For some attributes, the pace of change may not be easily discernibly by viewers. However for animations like motion, the ability to make the speed of the motion change gradually, and not in abrupt steps, can be important. The keySplines attribute provides this control.

Extending the above example to use keySplines:

<animate attributeName="x" dur="10s" values="0; 50; 100" 
     keyTimes="0; .8; 1" calcMode="spline" 
     keySplines=".5 0 .5 1; 0 0 1 1" />

The keyTimes still cause the "x" attribute to have a value of "0" at the start of the animation, "50" after 8 seconds and "100" at the end of the animation. However, the keySplines values define a curve for pacing the interpolation between values. In the example above, the spline causes an ease-in and ease-out effect between time 0 and 8 seconds (i.e. between keyTimes 0 and .8, and values "0" and "50"), but a strict linear interpolation between 8 seconds and the end (i.e. between keyTimes .8 and 1, and values "50" and "100"). Figure 7 shows the curves that these keySplines values define.

Figure 7 - Illustration of keySplines effect

	keySplines="0 0 1 1" (the default)		keySplines=".5 0 .5 1"
	keySplines="0 .75 .25 1"		keySplines="1 0 .25 .25"

Each diagram in Figure 7 illustrates the effect of keySplines settings for a single interval (i.e. between the associated pairs of values in the keyTimes and values lists.). The horizontal axis can be thought of as the input value for the unit progress of interpolation within the interval - i.e. the pace with which interpolation proceeds along the given interval. The vertical axis is the resulting value for the unit progress, yielded by the keySplines function. Another way of describing this is that the horizontal axis is the input unit time for the interval, and the vertical axis is the output unit time. See also the section Timing and real-world clock times.

To illustrate the calculations, consider the simple example:

<animate dur="4s" values="10; 20" keyTimes="0; 1"
     calcMode="spline" keySplines={as in table} />

Using the keySplines values for each of the four cases above, the approximate interpolated values as the animation proceeds are:

keySplines values	Initial value	After 1s	After 2s	After 3s	Final value
0 0 1 1	10.0	12.5	15.0	17.5	20.0
.5 0 .5 1	10.0	11.0	15.0	19.0	20.0
0 .75 .25 1	10.0	18.0	19.3	19.8	20.0
1 0 .25 .25	10.0	10.1	10.6	16.9	20.0

For a formal definition of Bezier spline calculation, see [COMP-GRAPHICS], pages 488-491.

The keyTimes and keySplines attributes can also be used with the from/to/by shorthand forms for specifying values, as in the following example:

<animate attributeName="foo" from="10" to="20" 
     dur="10s" keyTimes="0.0; 1.0"
     calcMode="spline" keySplines=".5 0 .5 1" />

The value will change from 10 to 20, using an "ease-in/ease-out" curve specified by the keySplines values. The keyTimes values cause the value of 20 to be reached at 10 seconds.

The following example describes a somewhat unusual usage, a from-to animation with discrete animation. The stroke-linecap attribute of SVG elements takes a string, and so implies a calcMode of discrete. The animation will set the stroke-linecap attribute to round for 5 seconds (half the simple duration) and then set the stroke-linecap to square for 5 seconds.

<rect stroke-linecap="butt"...>
   <animate attributeName="stroke-linecap" 
      from="round" to="square" dur="10s"/>
</rect>

This section is informative.

The SMIL 3.0 specification leaves the functionality SMIL 2.1 Content Control Modules [SMIL21-content-control] unchanged. 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 only 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.

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

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

<smil>
  <head>
    <layout>
       <!-- define projection regions -->
    </layout>
    <customAttributes>
      <customTest id="west-coast" title="West Coast Edition" 
        defaultState="false" override="visible"  
        uid="http://defs.example.org/user-settings/west-coast" />
      <customTest id="east-coast" title="East Coast Edition" 
        defaultState="false" override="visible" 
        uid="http://defs.example.org/user-settings/east-coast" />
      <customTest id="far-north"  title="Northern Edition"
        defaultState="false" override="visible"
        uid="http://defs.example.org/user-settings/far-north" />
      <customTest 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>