Re: TTML2 anonymous inline region creation

From: Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>> Date: Tuesday, 20 October 2015 17:03

On Tue, Oct 20, 2015 at 8:48 AM, Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>> wrote:
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;

I think that's what I'm suggesting when I say that an anonymous inline <set> element is created.



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]

[1] https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#semantics-style-resolution-processing-sss


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

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;

That's what I'd expect also.



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

We already have an implied exclusion set because some style attributes that affect regions are permitted on content elements and create anonymous inline regions but others do not. My lists are coincident with those two sets. To remove the current implied exclusion sets we would need to permit all style attributes on regions and all content elements and those that only have an effect on regions would create an anonymous inline [region|set].

I quite like the sets as they are – they seem to make sense.



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<https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#terms-content-element> can only be associated with a single region<https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#terms-region>. Consequently, if a content element<https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#terms-content-element> specifies a region<https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#layout-attribute-region> attribute, then any implied inline region specification or explicit inline region specification is ignored. If the content element<https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#terms-content-element> does not specify a region<https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#layout-attribute-region> attribute, but it includes both an implied inline region specification and an explicit inline region specification, then the former is ignored in favor of the latter."

[2] https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#semantics-inline-regions


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

[3] https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#procedure-associate-region


Interesting. Then the other approach we could take is to start with the explicit region specification and modify it with the attributes of the implied inline region to synthesise a new anonymous region. In other words, specify how the set of regions is merged to create a single region that the content goes into.



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

Sounds neat.



Nigel



-----------------------------
http://www.bbc.co.uk

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:22:49 UTC