Re: TTML2 anonymous inline region creation

On Tue, Oct 20, 2015 at 8:48 AM, Nigel Megitt <>

> All,
> Right now in TTML2 if a style attribute is specified on a p element that
> only has an effect on regions then an anonymous inline region is created.
> The style attribute inheritance chain is:
> >initial values -> anonymous region -> body -> div ... -> p -> span ...
> In considering how to fix tts:disparity it occurred to me that this isn't
> always what document authors might want or indeed expect.
> Another idea that I'm considering is: change from creating an anonymous
> inline region to creating an anonymous inline <set> element whose target
> is the region that applies to the element on which it applies and whose
> timing is coincident with the timing of the same element.

keep in mind that animation elements {animate, set} do not specify the
associated element to which animation applies; rather, they are associated
with an element either by context (in the case of an inline animation
element) or by the use of the @animate attribute on a content element;

so the content effectively points at the animation rather than the
animation pointing at content (or region) elements;

> In case of temporally overlapping elements that set the same style
> attributes to different values I would resolve the conflict using a
> begin-time-then-document-order rule, where last one wins.

this is already dealt with in step (5) [animation styling] of [1]


though I see I need to update that step to handle references to out-of-line

note also that in the current specified style set algorithm, if multiple
specifications contribute to a given style, then the last one applied wins,
not the first one;

> This would apply to the following style attributes that only have an
> effect on regions: tts:disparity, tts:extent, tts:origin, tts:position and
> tts:zIndex. I would probably exclude tts:displayAlign, tts:overflow,
> tts:showBackground and tts:writingMode because changing those on the fly
> would be weird.

in general, we have found it easier and more consistent to allow (at least
discrete) animation of all styles, even if one might not use them very
often (or ever); so i would not want to create an exclusion set here

> I'm just thinking this through right now, not definitively proposing it.
> The main thing I'm worried about is how the current solution interacts
> with issue-341 and issue-368. Even if we do go down the route of creating
> anonymous inline regions I imagine that authors will want a semantic like
> "just like a template region but with the specified style attributes
> differing", where the template region is the one that would have applied
> in the absence of the region-based style attributes on the p. That would
> also require a change to the inheritance chain, which would then be:
> Initial values -> specified region (if any) ... -> anonymous region ->
> body -> div … -> p -> span …

the note under [2] indicates

"A content element
only be associated with a single region
Consequently, if a content element
a region
then any *implied inline region specification* or *explicit inline region
specification* is ignored. If the content element
not specify a region
but it includes both an *implied inline region specification* and an *explicit
inline region specification*, then the former is ignored in favor of the


there is an editorial note under [3] to add normative language that effects
the above informatively described semantics


> Any thoughts on this appreciated, even if they're "Aargh don't change it
> now"!

perhaps we could introduce the ability for an inline animation to target
its region; i'll give this some thought

> Nigel
> -----------------------------
> This e-mail (and any attachments) is confidential and
> may contain personal views which are not the views of the BBC unless
> specifically stated.
> If you have received it in
> error, please delete it from your system.
> Do not use, copy or disclose the
> information in any way nor act in reliance on it and notify the sender
> immediately.
> Please note that the BBC monitors e-mails
> sent or received.
> Further communication will signify your consent to
> this.
> -----------------------------

Received on Tuesday, 20 October 2015 16:04:04 UTC