Differences from SMIL Timesheets draft

timeAction attribute

timeAction attribute is included in the SMIL Timing specification(*). However, the SMIL Timesheets draft does not mention any timeAction attribute. This attribute is essential because it specifies how an element is activated in terms of CSS properties.

Additionally, the timesheet scheduler sets a 3-state smil custom attribute to targeted elements, containing values idle | active | done, corresponding to before | during | after element activation respectively. This attribute can be used in CSS selectors to specify style or transitions for the different states.

(*) http://www.w3.org/TR/SMIL3/smil-timing.html#Timing-timeActionAttribute

mediaSync attribute

The SMIL Timesheets draft does not mention any way to synchronize explicitly a time container with a continuous media. The SMIL Timing recommendation defines a boolean syncMaster attribute on media elements, to synchronize other elements in the time container to this element.

However, syncMaster attribute is a bit inconvenient for our type of applications, because it forces to nest the video|audio element in the time container; for example, this is not semantically appropriate with seq/excl containers.

The mediaSync attribute refers to a continuous media element through a CSS selector (in order to be consistent with the timesheet-specific 'select' attribute). This attribute was proposed in this other project at INRIA:
http://wam.inrialpes.fr/timesheets/

Implementing prefetch

Our engine does not implement <prefetch> element mentioned in SMIL Timesheets draft. I propose an alternative approach in this page:
https://bitbucket.org/tadp/timesheets/wiki/prefetch

Bubbling of timing events

As mentioned in the SMIL Timing module, SMIL target nodes fire begin and end DOM events when activated and deactivated, respectively. The spec defines that the events do not bubble (*), i.e. an event triggered on a node is not propagated to higher-level nodes in the DOM. However, in our Timesheet engine these DOM events do bubble; so our engine differs from the standard on this issue. Bubbling allows to use "event delegation" in applications. This is very useful for two main reasons:

• It's more efficient when handling large number of events. Event delegation avoids having to add an event listener on each of the child nodes of a container.
• In dynamic applications, new nodes can be added to the DOM, and thus you'd need to attach the event listeners to each node when it's added. However, using event delegation we just add the event listeners to the parent container.

(*)http://www.w3.org/TR/SMIL3/smil-timing.html#q139

Event naming

Also, the names of events fired internally don't include the suffix "Event": In SMIL Timing (and SMIL Timesheets draft), the events specified are "beginEvent" and "endEvent", but in our engine the events are named "begin" and "end". The reasons for this difference are:

• Adding the suffix "Event" to an event name is verbose and unnecessary
• To be consistent with event names used in web applications, eg. "click", "mousedown", etc

restart= 'whenNotActive'

SMIL Timesheets draft does not mention about restart behavior. SMIL Timing recommendation defines as default behavior restart="always". However, Our supported behavior for restart is 'whenNotActive'. That means 2 things:

• an started item can't be restarted until its active end. ie. it does not listen for 'begin' events while it's active.
• items having 'begin' attribute with event-values can be restarted always. ie. when the item ends, if the 'begin' event triggers again, the item will start again. So at the moment developers can't prevent an item from been activated twice.

Should our SMIL Timesheets support other values for restart? I don't know.. there might be cases/apps in which developers want to define a different behavior than 'whenNotActive'. So, what do you think?

first/last/prev/next on <seq> container

SMIL Timesheets draft says that first/last/prev/next attributes can only be used for the 'excl' container. I don't understand the reasons why to not use them in 'seq' containers. To me it makes sense to use such navigation features in a seq container too (for certain use-cases). Thus, our engine supports those attributes in both excl and seq containers.

Implicit duration of discrete media is "indefinite"

The SMIL Timing spec says that the implicit duration of discrete media (aka. "static" media) is 0 (*). However, that default value turned out to be not intuitive. For static media (eg. images, text) it seems more intuitive to use "indefinite" as the default. That is, for an element that ends upon an event, one assumes you can omit 'dur' attribute. However, in the approach defined in the spec (as I understand it), if a developer omits 'dur' attribute in an image, the element will be deactivated immediately. It seems more intuitive to think that the image stays active unless indicated otherwise. This could be problematic for new people using our platform and that's why I changed the approach in our engine.

(*) http://www.w3.org/TR/SMIL3/smil-timing.html#q12