- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Tue, 20 Oct 2015 16:22:14 +0000
- To: Glenn Adams <glenn@skynav.com>
- CC: Timed Text Working Group <public-tt@w3.org>
- Message-ID: <D24C2715.2A1E6%nigel.megitt@bbc.co.uk>
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