Re: Timing behavior of animations children within a sequential timeContainer parent

Hi Alexander,

Thank you for asking about this.

My answer is: yes, when computing the times of an <animate>, <animation> or <set> element the implementation needs to take account of the computed value of the timeContainer attribute of its parent element.

In the example you reference, the described behaviour would indeed be different if the parent element did not set timeContainer="seq" but had timeContainer="par" instead.

Regarding your last question, about the applicable time container semantics for an <animation> element, see the semantics defined in §13.2.1 animate<https://www.w3.org/TR/ttml2/#animation-attribute-animate>, which are that the out of line animation is a syntactic shorthand for reproducing the sub-tree of each <animation> element under the referencing timed element, which should happen before animation timing is computed. That means that the value of timeContainer in the referencing element is the one that applies.

I hope this helps,

Nigel


From: Alexander Cerutti <cerutti.alexander@gmail.com>
Date: Tuesday, 3 February 2026 at 21:03
To: "public-tt@w3.org" <public-tt@w3.org>
Subject: Timing behavior of animations children within a sequential timeContainer parent
Resent from: List moderator <sysbot+mod@w3.org>
Resent date: Tuesday, 3 February 2026 at 21:03


External: Think before clicking
Hi everyone,

While introducing the support to <animate>, <animation> and <set> to my TTML engine, a new doubt came across.

Are these elements influenced by the timeContainer attribute as well? I gave a look at TTML document and to both SMIL and SVG specifications but didn't find a precise answer.

Although it may sound logical that the following two animations start at 0s and run as parallel (as per the timeContainer), this idea clashes in the other side of my brain, which says that defining two or more <animate> (or <set>) like this, seem to define two animations that run sequentially.

```xml
<p timeContainer="par" dur="10s">
    <animate tts:color="red;blue" dur="5s" />
    <animate tts:opacity="0;0.5" dur="6s" />
</p>
```

So, if timeContainer='par' applies to the <animate>, only parallel is possible (unless otherwise specified), but if it doesn't, is a sequential behavior implicitly applied?

Let's take the example at "Example Fragment – Region Style Animation".

```xml
<tt xml:lang="" xmlns="http://www.w3.org/ns/ttml"
    xmlns:ttp="http://www.w3.org/ns/ttml#parameter"
    xmlns:tts="http://www.w3.org/ns/ttml#styling"
    ttp:extent="640px 480px">
    <head>
      <layout>
<region xml:id="r1" timeContainer="seq" tts:opacity="0">
 <animate dur="1s" tts:opacity="0;1"/>
 <set dur="5s" tts:opacity="1"/>
 <animate dur="1s" tts:opacity="1;0"/>
 <style tts:extent="480px 60px"/>
 <style tts:origin="80px 400px"/>
</region>
      </layout>
    </head>
    <body region="r1">...</body>
</tt>
```

The note right after it, says:

In the above example, a region, r1, is initially set to 0% opacity, fully transparent, then is faded in to 100% opacity, fully opaque, over a one second interval. Opacity remains at 100% for five more seconds, and then is faded out to 0% over a one second interval, where it remains.

Does the described behavior apply because of the timeContainer='seq' applied to the region element or is this the default behavior for all the animations?

Hence, when <animation> defines some <animate> and <set>, as it isn't allowed to have a timeContainer, does this imply that the timeContainer used is the one of the element that references the animation (through the animate attribute)?

Thank you,
Alexander

Received on Wednesday, 4 February 2026 14:52:32 UTC