previous   next   contents  


11. Integrating SMIL Timing into Other XML-Based Languages

Erik Hodge ( (RealNetworks)
Warner ten Kate ( (Philips Electronics)

Table of contents

11.1 Abstract

This segment of the working draft specifies an architecture for applying timing information to XML documents. It specifies the syntax and semantics of the constructs that provide timing information. This approach builds on SMIL by preserving SMIL's timing model and maintaining the semantics of SMIL constructs.

The two non-In-Line Timing paradigms mentioned in this section of the working draft, namely CSS Timing and Timesheets, have not been given as much consideration by the SYMM Working Group as has In-Line Timing. The Working Group will continue to concentrate on solidifying In-Line Timing before it revisits other possible methods of adding timing such as CSS Timing and Timesheets.

11.2 Introduction

Currently there exists no standardized method for adding timing to elements in any arbitrary XML document. This segment of the working draft defines the mechanisms for doing so.

11.2.1 Background

Prior to SMIL 1.0 becoming a W3C recommendation, a significant number of W3C members expressed interest in integrating SMIL timing functionality with XML-based languages such as [XHTML10].

SMIL 1.0 describes timing relationships between objects, including complete XML documents. SMIL 1.0 can not control the timing of individual elements contained within these documents, e.g., the display of a single [XHTML10] heading before the bulk body text appears, or the sequential display of the items of a group in an  [SVG] document. When using SMIL 1.0 for this, a content author is forced to contain each temporal element set in a separate document, leading to very small documents in some cases.

As another example, consider the split up of text that would occur when creating closed captioning from a subtitle track using SMIL 1.0 if the text was in raw-text or HTML form, two standard text data types that do not contain native timing. Using SMIL timing, a text data type could be developed that would handle the presentation of each caption as contained within one file. The SMIL file would then only have to reference that one stream.

The SMIL 1.0 architecture assumes that SMIL documents will be played by a SMIL-based presentation environment. It does not treat the case where timing is an auxiliary component, and the presentation environment is defined by another language, like [XHTML10], a vector-graphics language like [SVG], or any user-defined XML-based language and stylesheet.

This segment of the working draft specifies how SMIL timing can be used in other XML languages, providing a solution to the above cases. This version of this segment of the working draft only concentrates on In-line Timing; future versions may include concepts like CSS Timing, where SMIL timing would be handled using CSS, and possibly other methods of externally adding timing to a document. The work is driven by the following goals:

11.2.2 Use cases

The following cases require the application of timing. These use cases are not listed in any particular order:

  1. Change media presentation over time.
    Various media objects contained in or referenced in an XML-based document are made to appear and disappear over time. Note: the media can be any element that models content: a video, a paragraph, a database record, etc. An example is a series of images and captions timed to appear as a slide show.

  2. Schedule the presentation of elements of a Web page.
    E.g., an HTML[*] page could be made to change over time by controlling the display of its elements.

    [*] Note: This assumes that the HTML document is a valid XML 1.0 [XML10] document.

  3. Add timing to an immutable document.
    Without modifying the original content document due to copyright and/or other issues, apply an external timing document to that content document. In some cases, timing will be applied externally to elements based on the names of their XML mark-up tags, while in other cases timing will be applied externally to elements of certain classes or to individual elements based on their unique IDs. For example, The Daisy Consortium's "talking book" applications use HTML documents containing the text of a book whose pages are marked with <SPAN> elements containing unique IDs. An external timing document could then be used to apply unique timing to each of these <SPAN> elements.

  4. Add timing to links.
    Links could be made to be active only during certain periods.
    Note: this can already be done within a SMIL 1.0 document.

  5. Change the appearance of graphical objects over time.
    For example, add timing to elements of a graphical display so that individual graphical elements appear, disappear, and move in front of and behind each other over time.

  6. Change the style, as opposed to the visibility, of textual data over time.
    For example, make something appear red for 5 seconds and then yellow for the remainder of its duration.

11.2.3 Assumptions

  1. The XML language to which the timing is applied can be of any type. The language can be:
  2. For CSS or other stylesheet-specified timing, the XML language must be able to cooperate with a stylesheet. The style language used is assumed to be CSS or another style language like  the Extensible Style Language [XSL].

Assumptions that may need further refinement

  1. The XML language of the document can cooperate with the document's Document Object Model (DOM), if one exists.
  2. If the full document, made up of the content document plus any external (non-in-line) timing, is exposed to the content document's DOM, that DOM models the data along the tree as spanned in the body.

11.2.4 Requirements

  1. Should follow the SMIL time model as it evolves.
  2. Should be compatible/interoperable with SMIL as specified in the goal number two.
  3. Should be possible to apply the timing model to any XML language.
  4. Should enable timing of styles as specified in the stylesheet accompanying the XML document.
  5. Should cooperate with events as specified by the content document's DOM.
  6. Any (allowed) mutations should be reflected appropriately in the time model, in a dynamic manner. For example, if a media element's begin time is based on the end time of another media element that has ended early, the former should begin right away rather than wait until its originally-scheduled begin time is reached.
  7. These requirements only apply to Timing methods other than In-Line Timing:
    1. Should enable authoring across documents, e.g., temporal specification may be separated from the content document.
    2. Should enable construction of temporal templates, such that timing styles can be developed and taken as an authoring basis for further refinement. The precedence rules are the same as for CSS.

11.3 Framework

This section outlines the conceptual approach to adding timing to XML languages. The Specification section specifies the constructs used. There are several methods of adding this timing, but this version of this segment of the working draft considers only method number 1, below, in any detail. Note that the second and third methods will require considerable refinement and are only mentioned in this document to show their potential for adding timing in cases where doing so using the first method is either not possible or is less efficient:

  1. Through In-line Timing. In-line timing is simply the addition of timing syntax into a content document to schedule the presentation of its objects.  This does not include any timing done through CSS or other style sheet timing methods even if the style sheet is "in-line", i.e., exists within the XML document to which it applies.  "In-line" in this section of the working draft refers only to adding  SMIL timing attributes to XML elements as well as adding SMIL time container elements to the body of the content XML document.
  2. Future Methods Under Consideration:

How to ensure that In-line Timing cooperates uniformly with CSS Timing or Timesheets is still under consideration.

In cases where SMIL timing is placed within an XML document, a hybrid DTD may be needed containing the DTD for the SMIL Timing and Synchronization module as well as the DTD for the XML language in which the original content document was written.

11.3.1 Framework: In-line Timing

In some cases In-line Timing will make authoring easier, especially in cases where the author wants the timing to flow with the structure of the content. In other cases, CSS Timing or Timesheets may be needed.

The semantics of In-line Timing are the same as that of SMIL Boston timing, but the syntax can differ. This module defines two ways to add In-line Timing to XML content.  These two methods may be used in combination:

  1. The first is to add SMIL time container elements <par>...</par>, <seq>...</seq>, and <excl>...</excl> to create time blocks that apply timing to all child elements. Legal SMIL Boston timing attributes, such as begin , end, and dur, could be added to these elements as well as to the resultant child elements.  For instance, an author could place a <seq> element as a parent of a list of items, then add dur="5s" to each list item element, and consequently make those list items display one after the other for five seconds each.
  2. The second way is to add timing container functionality to some of the existing XML mark-up elements. This has the advantage of not requiring the use of an additional element that might make it harder to manage the layout and other behavior of the document.
    Essentially, and element is made to act as a parent par, seq, or excl, and may also contain optional SMIL timing attributes like duration, begin time (relative to that of any parent element), and end time, to name a few. In order to declare that an element should act as a time container, a new attribute, "timeContainer", is defined. This attribute is only legal within grouping elements in XML documents, and specifically cannot be applied to any of the time container elements including par, seq and excl. The use of this attribute in a document does not preclude the use of par, seq, and excl elements within that same document.  A language designer may place additional constraints on the elements that can support the "timeContainer" attribute.
    Children of an element with this attribute have the same semantics as children of the respective time container elements as specified in the SMIL Timing module of this working draft.

This example adds timing to an [XHTML10] <DIV> element so that it acts as a <par> SMIL time container and has a duration of display of 10 seconds:
<div timeContainer="par" dur="10s">.

Besides adding timing to the display of objects within an XML document, varying styles like color and location over time may also be desired. This can be done two ways:

  1. By using a new attribute called "timeAction".  This attribute is the action associated with the timing. This attribute would allow the author to specify how the element's timing should be applied, e.g., to the display of its content or to style attributes like the color of its content. In SMIL 1.0, the begin, end, duration, and other times specified in elements are always used to place the element on its parent element's time line. This new attribute, timeAction, was created to allow alternate application of the specified time values, e.g., the begin time could be applied to a style like the color of an element without affecting the true begin time of the element.  For example, the following would make an [XHTML10] paragraph appear red for 5 seconds and then black for the remainder of its duration.  This example assumes that CSS class "redText" is defined for the document:
    <span class="redText"
       timeAction="class" dur="5s">This text will be red for 5 seconds and then
      black thereafter</span>

    The legal values for timeAction must be specified by the host language.

  2. By using SMIL Animation [SMIL-ANIMATION]. Like timeAction, this allows timing to be applied to elements' attributes such as style. Unlike timeAction, SMIL animation allows for timing to be applied to multiple attributes of an element.  For example, making the contents of an [XHTML10] paragraph be black for five seconds and then red for five seconds (at times relative to the parent's time line) while at the same time setting the duration of the display of that paragraph to 20 seconds, could be done as follows. This example assumes that CSS classes "blackText" and "redText" are defined for the document. Note that class takes a string, thus a calcMode of discrete applies. The animation will set the fontStyle to "blackText" for 5 seconds (half the simple duration) and then set the fontStyle to "redText" for the remaining 5 seconds of the animate element's duration:
    <p class="blackText" dur="20s">
      <animate attributeName="class" from="blackText"
              to="redText" dur="10s"/>
      This text appears in black for five seconds, then changes to
      red for five more seconds.  It changes back to black when the
      animate element's duration is reached at 10 seconds because
      the default fill is "remove" for the animation.  The dur of
      the p element applies to the display of the paragraph, not to
      the style.

Here is another, more-detailed example of In-line Timing being used to schedule the application of color style attributes as specified in the XML document's style sheet: Consider the playback of a music album where the audio track plays in concert with a list of the songs. Timing is added to the list so that the song that is currently playing is colored differently from the others. A <set> element from SMIL Animation in this example is used to set the style of the class "playing" (only) to the text during the time specified. Note that, in this example, the text of the paragraphs, namely "song 1", "song 2", and "song 3", all appear throughout the entire presentation; it is only their color that has been modified over time using (in-line) timing:

    .stopped { color: black; }
    .playing { color: red; }
<body timeContainer="par">
      <audio id="song1" src="" />
      <audio id="song2" src="" />
      <audio id="song3" src="" />
  <p class="stopped">
    <set begin="song1.begin" end="song1.end"
         attributeName="class" to="playing" />
    song 1
  <p class="stopped">
    <set begin="song2.begin" end="song2.end"
         attributeName="class" to="playing" />
    song 2
  <p class="stopped">
    <set begin="song3.begin" end="song3.end"
         attributeName="class" to="playing" />
    song 3

11.3.2 Framework: Future Frameworks Under Consideration

Future Framework: Cascading Style Sheet Timing

See Appendix B: Future Framework: Cascading Style Sheet Timing for one possible method of applying timing that may be considered by the SYMM Working Group after In-Line Timing is defined.

Future Framework: Timesheets

See Appendix C: Future Framework: Timesheets for another possible method of applying timing that may be considered by the SYMM Working Group after In-Line Timing is defined.

11.4 Specification

This section will precisely define the syntax and semantics of each method of integrating SMIL timing into XML-based documents.

11.4.1 Specification: In-line Timing

This section specifies In-line timing syntax.

Time Container elements:

All time container elements defined in the SMIL Timing module may be used, along with their respective legal attributes. These elements are predefined time container elements.

The "timeContainer" attribute:

XML elements other than existing time container elements may be made into time container elements through the "timeContainer" attribute. These elements become declared time container elements. An XML language designer may place additional constraints on the elements that can support the "timeContainer" attribute. The syntax is:


where "t" is any valid time container defined in the SMIL Timing module, including "par", "seq", and "excl", or "none":

Legal values are:

Defines a parallel time container with the same timing and synchronization semantics as a par element.
Defines a sequence time container with the same timing and synchronization semantics as a seq element.
Defines an exclusive time container with the same timing and synchronization semantics as an excl element.
Default value.  Defines the current element to not have time container behavior (i.e. to behave as a simple time leaf).

Timing Attributes for Child Elements of Time Container Elements:

All child elements of both predefined and declared time container elements may contain any legal timing attributes defined for media elements as specified in the SMIL Timing module.

Any document using in-line timing markup that is not within a predefined or declared time container behaves as if the document's body is wrapped in a <par>/</par>.

The timeAction attribute:

The legal values for timeAction must be specified by the host language.  These values could include: "display" (a reasonable default value) to make an element appear and disappear on its parent's time line, "visibility" to make an element appear and disappear visibly without affecting its presentation space, and "class" to apply the associated timing to the element's style class.


Note: the In-line Timing Framework section contains several examples using SMIL timing.

11.4.2 Specification: Future Specifications Under Consideration

Future Specification: CSS Timing

See Appendix D: Future Specification: CSS Timing.

Future Specification: Timesheets

See Appendix E: Future Specification: Timesheets.

Cascading Rules

In the case where in-line timing and another method are active simultaneously, in-line timing takes precedence if a conflict arises. This enables the creation of CSS Timing or Timesheets to be used as templates whose rules can be easily modified locally by in-line constructs.  The only exception to this rule is the ability for something like a user-stylesheet to be applied, such that !important rules are not overridden by inline timing. This would allow special stylesheets to control the timing in accessibility cases as well as other cases where user-specific timing may be desired. Thus, as is true for SMIL Animation as well as CSS, a user-stylesheet !important rule is always on top.

Integrating SMIL Timing into a host XML language

This section describes what a language designer must actually do to specify the integration of SMIL Timing into a host  XML language. This includes basic host language definitions, and constraints upon timing.

Required host language definitions

The host language designer must define some basic concepts in the context of the host language to which timing will be integrated.

The host language designer must define what "presenting a document" means. A typical example is that the document is displayed on a computer screen.

The host language designer must explicitly define the begin time of a document, i.e, does the document begin when the complete document has been received by a client (possibly over a network), does the document begin when certain document parts have been received, ...etc.  This is important so that different applications that play these documents will provide the same end-user experience under the same conditions.

The host language designer must define the end time of the document. This is typically when the associated application exits or switches context to another document.  The language designer may want to specify that an explicit "end" attribute be defined for the body element of each document, or that the body element has an indefinite duration.

The host language designer must specify which elements can be made into time containers, i.e., which elements support the "timeContainer" attribute, which support other timing attributes such as "begin" and "dur", and then what the behavior of the remaining timing-free elements is under different parent element timing conditions.

The host language designer must specify when an element can be considered made active and made inactive.  For example, an XHTML "b" element becoming active will only change the bold quality of text, which is something very different from the activation of a "div" element which causes a block of text to appear.  How the element acts based on its activation and deactivation must be specified for each element for the host language.

Error handling semantics

The host language designer may impose stricter constraints upon the error handling semantics. That is, in the case of syntax errors, the host language may specify additional or stricter mechanisms to be used to indicate an error. An example would be to stop all processing of the document, and to halt playback of the document if it had begun before the erroneous code was received by the parser.

SMIL Timing namespace

A namespace for the "timeContainer" and "timeAction" attributes will be located at

11.5 DTD

This section provides the formal specification for the inline-specific timing markup. Refer to the SMIL Boston timing module for specification of the generic set of timing elements and attributes.  Other timing markup methods to be defined will also include their DTD definitions here.

In-line Timing Syntax DTD definitions:

    <!ENTITY % integrateInlineTimingAttrs
      timeContainer  (par | seq | excl | none) "none"
      timeAction     CDATA              #IMPLIED

11.6 Appendix A. In-Line Method Examples

  1. Consider an XML-based image-list language. Each document contains a list of references to JPEG images. Timing of the images relative to one another is done in line. Here is an example of such a document, where each image in the list exists on the time line for its specified duration and is then replaced, both spatially as well as on the time line, by the next image. The final image will be active on the time line for only 8 of its 10-second duration because the parent is explicitly specified to end at that time. Note: the presentation of the elements is implied in this example.
    <imagelist timeContainer="seq" end="28s">
      <image dur="5s" src="image1.jpg" />
      <image dur="3s" src="image2.jpg" />
      <image dur="12s" src="image3.jpg" />
      <image dur="10s" src="image4.jpg" />

11.7 Appendix B. Future Framework: Cascading Style Sheet Timing

Reminder: the various syntaxes specified in this segment of the working draft are likely to change prior to the finalization of the working draft.

Still under discussion is whether the timing attributes are XML attributes or CSS properties, i.e., whether CSS style rules will be used to apply timing properties to XML elements, or whether the timing is an actual style property.  For this version of this segment of the working draft, we assume the latter but may switch to the former after further debate:

CSS Timing is the use of SMIL timing within a style sheet, where timing may be a style property, just like, for example, color and font-weight in CSS, that is applied to elements in the content document. The resultant timing structure is based on and depends on the structure of the content document. In some cases, in-line timing may be inefficient, difficult, or impossible to add particular timing. In these cases, either CSS Timing or Timesheets may be needed. Some possible cases where CSS Timing will provide a better solution than in-line timing are:

The same attributes mentioned in the In-Line Timing Framework section, above, will be needed. "timeContainer" is needed to be able to declare that an element should act as a time container. The "animate" element and/or the "timeAction" attribute is needed to be able to apply timing to a style applied to the object(s).

How to ensure that CSS timing and in-line timing cooperate uniformly is still under consideration.

Here is a simple example containing one possible syntax for integrating timing using CSS. In this example, the list will play in sequence as dictated by the style sheet in the HEAD section of the document. Note: the style sheet, like any CSS, could alternatively exist as a separate document.  Also, note that the timing applies, by default, to the display of the elements as opposed to the style of the elements:

      UL { timeContainer: seq; }
      LI { font-weight: bold; dur: 5s; }
      <LI>This list item will appear at 0 seconds
          and last until 5 seconds.
      <LI>This list item will appear after the prior
          one ends and last until 10 seconds.

11.8 Appendix C. Future Framework: Timesheets

Timesheets refer to both the conceptual model along which timing, including the structure of the timing, is integrated into an XML document, as well as one possible syntax implementation. This approach provides a solution where time can be brought to any XML document regardless of its syntax and semantics.

A Timesheet uses SMIL timing within a separate document or separate section of the content document and imposes that timing onto elements within the content document. The resultant timing structure is not necessarily related to the structure of the content document. Some possible cases where a Timesheet will provide a better solution than in-line timing are a superset of such CSS Timing cases (which are included in the list below):

11.8.1 Three document sections

Timesheets assume an XML document conceptually composed of three presentation related sections:

  1. the content part.
  2. the formatting part.
  3. the timing part.

The first section, content, relates to the particular XML document. It conforms to a DTD written for an XML language. The content part describes the media and its structure.

The second section, formatting, provides control of the properties of the elements in the content section. It conforms to a style language, which, for the purpose of this discussion, we assume to be CSS. The style section describes the style and (spatial) layout of presenting the content. "Formatting" might include matters like routing of audio signals to loudspeakers.

The third section, timing, provides control of the temporal relations between the elements in the content section. It conforms to SMIL's timing model. The time section describes the time at which content is presented as well as the time at which style is applied. The time section contains the information to prepare a presentation schedule.

Sections two and three provide presentation information to the content: the stylesheet on style and positional layout, the timesheet on temporal layout. The stylesheet and timesheet may influence each other, but there should be no circular dependencies.

The idea is that each section operates independent from and compliant with the others.

11.8.2 Principles

  1. The temporal structure is not necessarily implied by the content structure. Here is an example.
  2. A timesheet may not be sufficient to build a time graph to provide a timing structure. A timesheet can consist of independent rules (time relations), which, together with the content, build the timing graph. For example, a selector in a timesheet may apply to multiple items in the content.
  3. Unspecified timing may be left to the implementation to fill in. For example, items in a list can be declared to appear sequentially, while the temporal relations between lists and other content remain unspecified. When the author does not supply these, the template is still to be obeyed.
  4. A timesheet may over-specify time relations. Unused rules are ignored. Conflicting time relations which concern the same element are either resolved using the timesheet cascading rules (to be specified, e.g. in-line overrides a template) or are an error (also to be made explicit). For example, when the timesheet declares sequential presentation of list items, while there are none of them in the document, the rule is simply ignored. Another example is where two rules select list items specifying different durations, e.g., all list item elements have a duration of 5 seconds except the first in each list has a duration of 8 seconds.

Here is a simple example where a timesheet exists, but in-line timing is also specified and overrides the timing imposed by the timesheet:

This example has a timesheet that specifies that each "li" element will have a begin time of 10 seconds and a duration of 15 seconds. However, the in-line timing in the second "li" element has presidence over the timesheet and thus the second line item ends up having a begin time of 0 seconds and a duration of 5 seconds.  Note: this example could have been done just as easily using CSS Timing; the added power of Timesheets will be made clearer in the next example.

  li { begin=10s dur=15s }
  <li>This first line will begin at 10 sec and run for 15 sec.</li>
  <li begin="0s" dur="5s">This second line's timing is dictated
     by the in-line timing which overrides the timesheet timing
         for each child "<li>" element.  It will thus
         begin at 0 seconds and last 5 seconds.</li>

Following is an example showing some HTML extended with timing via a Timesheet. As with the CSS example, the Timesheet could just as well have been contained in a separate document and applied externally. CSS selector syntax [CSS-selectors] has been used. The use of CSS selectors here should not be confused with CSS Timing, proposed in the prior section of this segment of the working draft.
The expected presentation of this would be to have the two Headings appear together followed by the first list item in each list, namely Point A1 and Point B1, appearing at 3 seconds followed thereafter by the second list item in each list, namely Points A2 and B2, appearing at 6 seconds. All items would disappear at 10 seconds which is the duration of the outer <par>.

        <par dur="10">
            h1 {}
          <par begin="3">
            <!-- Selects the first LI in each list:        -->
            OL > LI:first-child { }
          <par begin="6">
            <!-- Selects the second LI in each list:        -->
            OL > LI:first-child + LI { }
      <h1>Heading A</h1>
        <li id="PA1">Point A1</li>
        <li id="PA2">Point A2</li>
      <h1>Heading B</h1>
        <li id="PB1">Point B1</li>
        <li id="PB2">Point B2</li>

Note: the property fields {.} could contain duration and syncarc relations if the author wished to add more complex timing.

Here is another example as mentioned in Use Case 2C. Assume a human body display language. In this example different parts appear and disappear in different combinations at different times regardless of the content structuring, i.e., regardless of the order of the data in the document body. The document DTD uses the human structure: human = { face, torso, 2 arms, 2 legs }. A leg has a thigh, knee, calf and foot. Etc. The document merely describes the structure of the human form. Here is an example of such a document:

         <face id="face" ...>
            <eye id="leftEye" color="green" .../>
            <eye id="rightEye" color="blue" .../>
         <arm id="leftArm" ...>
            <hand id="leftHand" .../>
         <leg id="leftLeg" ...>
            <thigh id="leftThigh" .../>
            <knee id="leftKnee" .../>
            <calf id="leftCalf" .../>
            <foot id="leftFoot" .../>

Both of the following examples are possible by applying a different timesheet in each case to the same XML document. For these examples, we use the XML "human" document, above. Note: these examples demonstrate the timesheet's ability to allow a content element to be displayed as if its parent were but with the parent not displayed, in other words the child element is displayed in the same place, spatially, as if the parent was displayed.  "These examples presume that the XML language allows a content element to be displayed as if the full document was, but with some parents not displayed. In other words the child element is displayed in the same place, spatially, as if the entire document was displayed. Not all XML languages support this."

11.9 Appendix D. Future Specification: CSS Timing

CSS timing syntax has not been specified, but several possibilities are under consideration.

The exact specification of CSS Timing selectors is still being considered. Selector algebra will most likely be that defined by CSS2 [CSS-selectors].

The CSS Timing Framework section contains an example using SMIL timing.

11.9.1 Timing style

In addition to selecting elements, style rules should be selectable. This enables changing style properties over time, just as we saw in the In-Line Timing color style example.

11.10 Appendix E. Future Specification: Timesheets

Timesheet syntax has not been specified, but several possibilities are under consideration. The Timesheets Framework section contains several examples (1, 2) using SMIL timing.

11.10.1 Structure copying

The structure of the body may be used to impose temporal semantics, where a time property is assigned to an element. It is important to realize that time relations are imposed between the elements selected. For instance, when selecting a <ol> in a <seq> relation, it means that the ordered list is going to be displayed after or before some other element. It does not mean that the list items contained by the ordered list are to be presented in a sequence.

In order to provide a syntax for denoting temporal relations in line with the body structure, a new type of selectors is added to those already available from CSS.

CSS has the notion of class selectors. These selectors imply that the rule (time relation) they are part of should be applied for each element in the body that is a member of that class.

Timesheets add a new type of class selectors, henceforth to be called structure selectors. These selectors imply that the time relation they are part of applies to the result of expanding the structure selector into id selectors of all elements in the body that are members of that structure class. The id selectors have to appear in the order in which the elements lexically appear in the body. In this way, by selecting the class of descendants, the structure of the body section can be copied into the time section, such that the copied structure receives the temporal semantics required.

11.10.2 Structure ownership

Another form of using the structure in the XML body is called ownership. Ownership dictates whether a temporal relationship imposed on an element applies to all of its descendants or only on the element itself. Ownership applies for example in the sequenced <ol> case when child <li> element(s) contain further markup. By specifying that ownership is on, the children of <li> element(s) will also take on the same temporal relationship as their parents.

11.10.3 Timesheet selectors

As discussed earlier, in timesheets there are two ways to expand class selectors:

  1. Class selector. The timesheet's rule applies per member in the class. This is the traditional CSS meaning; the timesheet's rule is repeated per element in that class.
  2. Structure selector. The timesheet's rule applies to the set elements resulting from expanding the class selector into all its elements. For example, a structure selector is used to create a <seq> of <li> without identifying all these <li> individually.

The exact specification of timesheet selectors is still being considered. Selector algebra will most likely be that defined by CSS2 [CSS-selectors] with some additional algebra defined as necessary.

11.11 Appendix F. CSS Timing, Timesheet, and other non-In-Line Examples

  1. This example uses CSS Timing to cause an otherwise static [XHTML10] list to grow over time, where each list item shows up below the prior item, 10 seconds after the prior item began its display. Because the UL becomes a "par" time container, its list items do not disappear until the UL's end time is reached.
    /*   style sheet document "growlist.css": */
    .seqtimecontainer { timeContainer:
        seq; dur: 30s} LI { dur: 10s; }
    <!-- HTML document (which happens to be well-formed XML): -->
       <LINK rel="stylesheet" type="text/css" href="growlist.css" />>
        <UL class="seqtimecontainer">
              <LI>This is item 1.  It appears from 0 to 30 seconds.
              <LI>This is item 2.  It appears from 10 to 30 seconds.
              <LI>This is item 3.  It appears from 20 to 30 seconds.
  2. Consider a document written in some graphics language where three big squares are layed out inside a rectangle, and each square contains a smaller square. We should be able to create a timesheet that can schedule the appearance of each square at different times from the others. Note: the presentation of the elements is implied in this example.
    <rectangle id="window" geometry="..." fill="...">
      <square id="b1" ... >
        <square id="s1" ... / >
      <square id="b2" ... >
        <square id="s2" ... / >
      <square id="b3" ... >
        <square id="s3" ... / >

    In order to time the presentation of the elements so that the big squares pop up one after the other, followed by the simultaneous appearance of the small ones, the timesheet might look like this:

          #b1 { dur: 2s }
          #b2 { dur: 2s; begin: 2s; }
          #b3 { dur: 2s; begin: 4s; }
          #s1 { }
          #s2 { }
          #s3 { }

    Note: the outer "window" rectangle has not been given any explicit timing. for this example, we assume that the lack of timing implies a begin time of zero and an indefinite duration if the element does not have an implicit duration.

previous   next   contents