Instead of trying to implement the whole SMIL/Timing spec, I’ve focused on four basic use cases:

Rotating Banner
a simple example to demonstrate the basic concepts of time containers
HTML Subtitles
synchronizing rich subtitles with a video stream
(requires <video> support)
Annotated Audio
synchronizing textual descriptions of musical sections and introducing declarative user interaction
(requires <audio> and SVG support)
Slideshow Engine
nesting time containers to create a highly flexible slideshow engine
This is the very first release of this Timesheet Scheduler (v0.1, MIT license). The next version should support event-values and open up a lot of user interaction possibilities.

Browser Requirements

This demo works with all modern browsers: Firefox 3.5+, Safari 5+, Chrome 5+, Opera 10.60+.

Firefox users: these demos work with Firefox 3.x but you’ll get a better experience with Firefox 4 (read: with CSS transition support).

Internet Explorer users: I’m afraid your browser isn’t supported yet — the IE9 support should come soon, though.

Timing Markup

Here’s an overview of the markup used in the first slideshow:

<div class="highlight" smil:timeContainer="excl" smil:first="restart.click">

  <div id="slide1" smil:begin="0:00" smil:timeContainer="par">
    <p> Ever wanted to… </p>
    <ul smil:timeContainer="par">
      <li smil:begin="0:02">
        create your own slideshow in HTML?
      </li>
      <li smil:begin="0:04">
        synchronize HTML content with multimedia streams?
        <small>(subtitles, transcriptions, annotations…)</small>
      </li>
      <li smil:begin="0:06">
        animate HTML elements?
      </li>
    </ul>
    <h2 smil:begin="0:08">
      …without writing any single line of JavaScript?
    </h2>
  </div>

  <div id="slide2" smil:begin="0:12" smil:timeContainer="par">
    […] 
  </div>

  <div id="slide3" smil:begin="0:24" smil:timeContainer="par">
    <dl smil:timeContainer="par">
      […] 
    </dl>
    <p smil:begin="0:04" class="menu">
      <a href="about.xhtml">Learn more…</a>
      <a href="#download">Download!</a>
      <button id="restart">Restart</button>
    </p>
  </div>

</div>

The markup is rather self-explanatory and relies on two basic concepts

  • time containers define the timing model of child nodes (<par>allel, <seq>uential or <excl>usive);
  • the "begin" and "dur" attributes provide a basing timing description. Yes, this is the same syntax as the one used in SVG Animations.

That’s simple and efficient. The four examples on labs.kompozer.net/timesheets should be a step-by-step tutorial, and I have a few other demos in mind that I’ll add with the next release of our timesheet scheduler.

References: SMIL Timing and Timesheets

The SMIL/Timing recommendation specifies two attributes, timeContainer and timeAction, to integrate timing and synchronization features into HTML documents:

The modularization of SMIL 3.0 functionality allows language designers to integrate SMIL Timing and Synchronization support into any XML language. In addition to just scheduling media elements as in SMIL language documents, timing may be applied to the elements of the host language. For example, the addition of timing to HTML (i.e. XHTML) elements will control the presentation of the HTML document over time, and to synchronize text and presentation with continuous media such as audio and video.

Two attributes are introduced to support these integration cases. The timeContainer attribute allows the author to specify that any XML language element has time container behavior. E.g., an HTML <ol> ordered list element may be defined to behave as a sequence time container. The timeAction attribute allows the author to specify what it means to apply timing to a given element.

The SMIL/Timesheets draft suggests another way to use SMIL/Timing (and SMIL/BasicAnimation) with HTML documents:

This language allows SMIL timing to be integrated into 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 (CSS) language, this functionality has been termed SMIL Timesheets.

SMIL Timesheets 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. And as with CSS, SMIL Timesheets can be reused in multiple documents, which can provide a common temporal framework for multimedia presentations with different contents but identical storylines.

In other words, we’re not re-inventing the wheel or thinking of another slideshow engine: we’re just implementing an official W3C recommendation.

What's The Point?

Web Browsers Already Support SMIL

No they don't.

Modern web browsers (read: all except Internet Explorer) support declarative SVG Animations, which rely on the SMIL/BasicAnimation module — hence the (common) confusion — but can't be used for HTML timing. They don't support the whole SMIL recommendation.

Why Don't You Implement SMIL Instead?

The SMIL spec is huge, it includes a specific box-model which is very far from the HTML/CSS one, and it's only partially implemented by a few media players. It might be possible to implement SMIL in modern web browsers, too, but we think it would be inadequate:

  • web authors would have to learn SMIL, which is much more difficult to use than HTML
  • we don't want to include a SMIL section in a web page: we want to control the timing of the whole web page!
  • HTML5 and CSS3 are already fine to describe the content and layout; all we need is a standard, declarative timing language.

SMIL has been designed for advanced synchronization tasks. Some SMIL aspects have already been ported to web standards (e.g. SVG animations and CSS transitions), our project is about porting SMIL/Timing and Timesheets to web documents.

I Can Already Do That With Flash/JavaScript

That's right. And you can still use JavaScript to get some rollover effects if you don't want to use the CSS :hover pseudo-class. ;-)

The point is precisely to use a declarative language for all the common tasks that currently require JavaScript development:

  • that's much easier for web authors (and for web authoring tool developers);
  • that's a much better way to achieve a good accessibility / indexability;
  • that's easier to maintain, since no specific JavaScript code is used.

As this declarative language is (almost) standard, web browsers could implement it eventually. Until then, we'll provide a free, generic, JavaScript implementation.

IE Already Supports HTML+Time And Nobody Cares

True: Microsoft started supporting HTML+TIME 10 years ago with IE 5.5; but without SVG, <audio|video> elements and CSS transitions, there hasn't been many real-life use cases so far.

We think it's more than time to bring a modern, standard equivalent of HTML+Time to the web. Especially for multimedia-related tasks.

Roadmap

Bugfixing: before starting to work on the new editor, I have to get a stable Timesheet Scheduler first. In case you want to contribute: this JS lib is open-source (MIT license), code reviews and patches are welcome.

Event-values support: I’m not planning to implement the whole SMIL/Timing spec but at the very least, I need a better event-values support to describe more complex user interactions. Our goal is to get a full-featured web documentary engine.

Internet Explorer support: IE9 should be relatively easy to support (though CSS transitions will probably not work on this browser), but for older IE versions this is gonna be tricky as this SMIL/Timing implementation focuses on media synchronization, and requires <audio|video> support. A solution would be to use <object> fallbacks targetting the Windows Media Player plugin and design a JavaScript layer that would expose an HTML5-like API to control these object nodes (i.e. play/pause and the “timeupdate” event). If you heard about such a library, please ping me.

Timesheet Editor: the final goal of this project is to get an easy-to-use, multimedia page authoring tool. It will be based on Kompozer / SeaMonkey Composer, which will leave me some time to port Kompozer to Gecko 2 and backport most of its code to SeaMonkey. Yes, somehow I’ll get paid to work on Kompozer! *\o/*

Many thanks to Anthony Ricaud for his tips, and to Kompozer contributors for their early feedback.