Support for conditional styling. #128

plehegar · 2015-11-04T19:12:13Z

Consider the use case in which an author wishes to permit the viewer of a TTML2 document to select from one of a number of style choices, either depending on a parameter or a media query, for example choices that vary tts:fontSize and tts:extent to accommodate 'normal size font', 'large size font' and 'small size font' options.

The condition attribute can only be used to omit an element from semantic processing, not to change its behaviour. One might imagine that the following is a way to proceed:

<layout>
<region xml:id="r1" condition="parameter(text_size)=='large size font'" tts:extent="95vw 30vh" .../>
<region xml:id="r1" condition="parameter(text_size)=='normal size font'" tts:extent="80vw 20vh" .../>
<region xml:id="r1" condition="parameter(text_size)=='small size font'" tts:extent="60vw 15vh" .../>
</layout>
<styling>
<style xml:id="sFontSize" condition="parameter(text_size)=='large size font'" tts:fontSize="15vh"/>
<style xml:id="sFontSize" condition="parameter(text_size)=='normal size font'" tts:fontSize="10vh"/>
<style xml:id="sFontSize" condition="parameter(text_size)=='small size font'" tts:fontSize="7.5vh"/>
<style xml:id="sDefaultFont" style="sFontSize" tts:fontFamily="myFontFamily"/>
</styling>
...
<body>
<div region="r1" style="sDefaultFont">
...
</div>
</body>

However this construct, which requires use of xml:id for style and region reference, breaks xml:id uniqueness rules, resulting in invalid documents. What options are there for achieving this use case? I can see:

a) repeating all the content in the document with different style and region references and specifying condition only on the content,

b) basing everything on the initial element and making that conditional (since nothing needs to refer to initial by xml:id), and specifying all regions inline - unfortunately this may be very verbose in terms of repeating regions on many content elements, but it could work for cases where there are only a few regions and they can be associated with body or div elements.

Neither of these two options is particularly attractive - a) is highly repetitious and offers no advantage over the provision of multiple documents with any associated costs for asset management and distribution there. b) is limited in basing style on initial so it is a 'one chance' condition, and it is potentially repetitious in region definition.

By the way, there are at least three audience groups for which this use case exists: 1) Those who have reading difficulties with normal size text; 2) users of different devices, where it has been established that text needs to be rendered at different sizes on large screen televisions from smartphones for example; 3) those who just want to be able to customise the display.

It would be great if the condition construct could be used to allow some predefined viewing options to be authored into the document, i.e. in a controlled way by the document author. I can't see how this can be achieved at present though.

What solution choices are there? Perhaps the easiest is to redefine the condition construct so that it also includes an 'if then else if' syntax in which attributes can be defined, so you might end up with, for example:

<region xml:id="r1" condition="if parameter(text_size)=='large size font' then (tts:extent='95vw 30vh' elseif parameter(text_size)='normal size font' then (tts:extent='80vw 20vh') elseif parameter(text_size)='small size font' then (tts:extent='60vw 15vh') else (tts:extent='80vw 20vh')"/>

Then xml:id rules are not broken and region r1 can be referenced safely with the attribute evaluation only being conditional. I'd advocate retaining the ability to specify a condition that can be used to exclude the entire element from semantic processing, as now.

Another solution to this problem might be to define some preprocessing using XPath to select specific elements and/or attributes and set values on the basis of the same condition functions that have already been specified, i.e. parameter, media, supports. Something like:

<tt [parameters etc]>
<preprocess xmlns="...">
 <rule condition="parameter(text_size)=='large size text'" path="//region[@xml:id='r1']">
   <attributes tts:extent="95vw 30vh">
 </rule>
</preprocess>
<head>
  <layout><region xml:id="r1"/></layout>
</head>
...
</tt>

It would be an error for a path attribute to refer to anywhere except or or their descendants.

This option would also have the incidental effect that it would provide similar functionality to declarative styling. All the rules would be executed in document order prior to processing the . Preprocessing could of course also be performed externally to the document before processing, if a 'user style' is desirable (as is the case for any XML document) .

(raised by Nigel Megitt on 2015-01-16)
From tracker issue http://www.w3.org/AudioVideo/TT/tracker/issues/366

skynavga · 2016-09-10T20:42:07Z

Since it will not be possible to break the uniqueness constraint without making content invalid XML, a different solution will be required for this use case.

nigelmegitt · 2016-09-10T20:55:48Z

@skynavga I'd appreciate your thoughts on the alternative solutions described in the issue.

nigelmegitt · 2016-09-20T15:27:59Z

Notes from 2016-09-20 f2f meeting: one option to consider here is to use a conditional set element that may optionally have no associated timing attributes, to apply region or style attributes based on some condition. That would probably work but may need some more thought.

palemieux · 2017-05-04T21:22:45Z

@nigelmegitt Are you still interested in adding this capability to TTML2? If so, can you suggest a PR based on the set approach mentioned in #128 (comment)? If not, ok to defer to TTML vNext?

skynavga · 2017-05-11T15:25:44Z

@skynavga please review and comment on this

nigelmegitt · 2017-05-14T19:22:33Z

@palemieux as discussed, yes, I believe this still needs to be addressed so that there are clear usable patterns for applying attributes based on condition that we can list by example. Using the set element looks like the cleanest way to me. From my recollection we discussed three possible approaches:

Possible approaches

1. Chained referential styling

This is where conditionally removed elements may still be referenced by other elements and define the behaviour in that case to be "do nothing", e.g.

<style xml:id="dependentStyleHighContrast" condition="parameter('high_contrast')='true'" tts:backgroundColor="#000000ff"/>
<style xml:id="dependentStyleNotHighContrast" condition="parameter('high_contrast')='false'" tts:backgroundColor="#00000080"/>
<style xml:id="backgroundStyle" style="dependentStyleHighContrast dependentStyleNotHighContrast"/>

This appears to be possible now (so in that case one might say that this "works for me") however I think it rather inelegant from an authoring perspective and even slightly weird. Still, if no other resolution can be found then this would work I suppose - I would really like there to be clear examples and probably an appendix describing this pattern.

Action point: Specifically, we need to explain/clarify in the style resolution process that a style whose condition evaluates to false results an empty style set, not that the exclusion of the element is intended to result in an IDREFS reference failure due to the element apparently not existing at all.

2a. Conditional anonymous `set` elements

Here we use aconditional anonymous set element to modify the applicable style set of a content or style element. This would require a modification to permit set to be a child of the style element. For example:

<style xml:id="backgroundStyle">
   <set condition="parameter('high_contrast')='true'" tts:backgroundColor="#000000ff"/>
   <set condition="parameter('high_contrast')='false'" tts:backgroundColor="#00000080"/>
</style>

By the way when we discussed this in Lisbon we realised it is related to the proposed change to make non-applicable style attributes on content elements, such as tts:origin or tts:extent on tt:p elements, act as anonymous sets that act on the currently active region.

2b. Styles reference `set` elements using the `animate` attribute.

This is a variant of 2a, in which the set elements are contained within an animation parent and the style element is permitted to include an animate attribute:

<style xml:id="backgroundStyle" animate="setHighContrast setNotHighContrast"/>
...
<animation>
   <set xml:id="setHighContrast" condition="parameter('high_contrast')='true'" tts:backgroundColor="#000000ff"/>
   <set xml:id="setNotHighContrast" condition="parameter('high_contrast')='false'" tts:backgroundColor="#00000080"/>
</animation>

Arguably this is simply a syntactic rearrangement of 1. above however it retains a single way to reference conditional behaviour rather than allowing that additionally into the style element.

My preferred choice

My key take-aways from this are:

Strictly, there are techniques available already in TTML2 to resolve the apparent issue.
I need them to be clarified, exemplified and explained (e.g. see bullet 4 below).
Option 2a. has several advantages so I would like to see it added:
- it is (to me) the most readable/understandable of the choices;
- it works in environments where chained referential styling is prohibited;
- it allows content elements to reference a single style and have the evaluation of that style change over time since the set element can include begin and end attributes, which presumably are resolved relative to the referring element's syncbase. This is a point of stylistic elegance more than anything else, since logically this must already be achievable some other way.
Option 1. will not be removed since we cannot sensibly remove it; however we need to add a Note to clarify that referencing a style whose condition evaluates to false returns an empty style set in the style resolution process. In other words, it does not make the element 'disappear', just its style attributes.
This mainly seems to be an issue with the style element, but there must be an analogous problem with the region element since the syntax region="r1 r2" is prohibited; instead the region itself must be modified to take different position, extent etc attributes in a conditional way. I would prefer that we had a single pattern used to solve to this problem that works equally for region and style, however it looks like fixing that would either a) be a huge change or b) should have happened a long time ago.

Looking forward to @skynavga 's comments and review on this also.

palemieux · 2017-05-15T06:00:58Z

When are condition expressions evaluated? At time of parsing or time of rendering or something else?

nigelmegitt · 2017-05-15T10:19:27Z

Evaluation time is currently undefined as far as I can tell.

skynavga · 2017-05-15T10:54:41Z

On Mon, May 15, 2017 at 4:19 AM, Nigel Megitt ***@***.***> wrote: Evaluation time is currently undefined as far as I can tell.

Yes, this needs to be defined, however, it may not be possible to do in a precise manner. Basically, the design is predicated on determining whether the semantics of a conditionalized element is ignored or not. So evaluation can theoretically be delayed until the time when those semantics are relevant, so what I know we can say is: - we should not force (premature) eager evaluation, i.e., we need to permit lazy evaluation; - evaluation must not occur more than once, i.e., the condition should not be re-evaluated every time its semantics need to be used;

nigelmegitt · 2017-05-15T11:12:20Z

evaluation must not occur more than once, i.e., the condition should
not be re-evaluated every time its semantics need to be used;

This is too limiting. For responsive scenarios such as windows that can be resized, that would modify the input data for the equivalent of media queries, so it must be an available option to re-evaluate based on changing input data.

skynavga · 2017-05-15T12:07:42Z

On Mon, May 15, 2017 at 5:12 AM, Nigel Megitt ***@***.***> wrote: - evaluation must not occur more than once, i.e., the condition should not be re-evaluated every time its semantics need to be used; This is too limiting. For responsive scenarios such as windows that can be resized, that would modify the input data for the equivalent of media queries, so it must be an available option to re-evaluate based on changing input data.

ok, that is a reasonable position

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#128 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXCb8XWBEKyh5PIF4Rb-5Nwc9tfsvQjks5r6DMUgaJpZM4GcAlv> .

palemieux · 2017-05-18T14:01:51Z

If condition is evaluated at arbitrary times, then 2(a) above increases processing complexity since referential styling resolution has to be deferred until condition is evaluated/changes.

What about simply using set on content elements, potentially using inheritance?

skynavga · 2017-05-18T16:26:27Z

Some preliminary comments, without reviewing the above:

@condition may be (re)evaluated at any time a dependent parameter changes, which, since some parameters derive from run-time state, means it may be re-evaluated at run-time;
the current spec text says that the semantics of an element are ignored when @condition evaluates to false; it does not say that the element is not parsed or not stored in the reduced infoset; indeed, it must be stored in the latter and potentially retained in ISDs for re-evaluation in the case that it references a run-time parameter (directly or indirectly);
the meaning of ignoring semantics may need qualifying for specific elements in order to retain partial semantics; e.g., I presently hold that the chained style references of a conditionalized <style/> element are retained; i.e., the chain is not broken, but the style attributes that the element would contribute are ignored;

At present, the TTT toolset implements the above semantics, and needs this behavior in order to support an effective mapping of the IMSC1 tts:forcedDisplay property.

I should also mention that the use and support of conditionalized styling does not prevent merging/flattening/reducing style specifications with respect to ISD instances; however, it does mean that conditionalized styling cannot be fully merged/flattened/reduced at ISD generation time.

nigelmegitt · 2017-05-18T16:47:27Z

I'm not sure yet where I stand on breaking/not breaking chains of referential styles, but it seems intuitive to me to expect conditionally excluded style to break the chain. Otherwise a larger group of styles might all need the same condition to be applied.

skynavga · 2017-05-18T16:53:16Z

@nigelmegitt or the author could merely collect into the conditionalized style all style attribute they think should be ignored (while retaining the chain overall);

nigelmegitt · 2017-05-19T08:42:05Z

@skynavga sorry, I don't follow you - please could you elaborate on #128 (comment) ? Are you saying that there should be an equivalent of tts:someStyleAttribute="fromChain" which could be put into a style element to explicitly cause chain breakage for that single style attribute in the event that the condition on the style element containing it resolves to false?

skynavga · 2017-05-19T14:10:32Z

I am saying that if you have

<style style="chain" condition="false" tts:color="" ... more styles .../>

then tts:color ... more styles ... is ignored, but that the chain remains active, i.e., that styles contributed from style="chain" are not ignored.

The context where this came up was in supporting IMSC1's tts:forcedDisplay, where it is necessary to insert a style as follows at the front of an existing chain:

<style style="chain" condition="parameter('forced')" tts:visibility="visible"/>

where chain references a chain of existing styles previously specified in the source IMSC1 document, e.g.,

IMSC1 Input

<style xml:id="s1" .../>
<style xml:id="s2" style="s1" .../>
...
<p style="s2" itts:forcedDisplay="true">Forced Display</p>

TTML2 Output

<style xml:id="s1" .../>
<style xml:id="s2" style="s1" .../>
<style xml:id="s3Generated" style="s2" condition="parameter('forced')" tts:visibility="visible"/>
...
<p style="s3Generated">Forced Display</p>

nigelmegitt · 2017-05-19T14:35:41Z

@skynavga okay, then what happens in this case:

<styling>
   <initial tts:color="blue"/>
   <style xml:id="s1" tts:color="yellow"/>
   <style xml:id="s2" style="s1" condition="false" tts:color="white"/>
</styling>
...
<p style="s2">Blue, white or yellow?</p>

In other words does the exclusion of a named style attribute cause all similarly named style attributes to be excluded or just the attribute defined in a context where the condition evaluates to false?

skynavga · 2017-05-19T14:37:18Z

yellow

nigelmegitt · 2017-05-19T14:44:49Z

Thanks, I understand, so the proposal is that it is impossible to break the chain, only to conditionally set some specified style attributes when condition evaluates to true. Makes some kind of sense I think. Now what about this:

<styling>
   <initial tts:color="blue"/>
   <style xml:id="s1" tts:color="lime"/>
   <style xml:id="s2" style="s1" condition="false"/> <!-- only there to define the chain? -->
   <style xml:id="s3" style="s2" tts:backgroundColor="black"/>
</styling>
...
<p style="s3">Lime or blue?</p>

in this example the conditional style defines no style attributes, so the assumption might be that the only thing the condition affects is the chain. But if I've understood correctly that isn't the case and the text comes out lime regardless?

skynavga · 2017-05-19T14:59:49Z

background color is black, from s3, and foreground color is lime, from s3->s2->s1

s2 doesn't specify any styles directly so the condition is vacuous in this case

nigelmegitt · 2017-05-19T15:38:23Z

Okay that's consistent, and should be covered by the already requested clarification of what the condition semantic includes (and excludes), possibly with an informative note to say that there is no way to break style chaining using condition.

Additionally, now that we have a bit more clarity about what is intended, we should also check that this approach does not exclude any use cases that we expect to be supported.

skynavga · 2017-05-29T21:40:39Z

Changing this issue to the question "how to conditionalize styles?". Since style vocabulary is already subject to @condition usage, what remains is to clarify how this is done and any special semantics that need to be defined, such as whether style chaining is broken when a style element's @condition evaluates to false.

skynavga · 2017-05-30T03:20:38Z

A few comments on #128 (comment) above:

the expression parameter('high_contrast')='true' is not only invalid but is also poorly expressed; it is invalid because the equals operator is == and not = (the latter is not a valid operator in the condition expression language); it is poorly expressed because it is not necessary to compare the value of the parameter function with a boolean; rather, the value of the parameter function can be used directly, e.g., condition="parameter('high_contrast')";
regarding the application of <set> to <style> and also the use of non-applicable styles to mean they apply to the current region, I have concluded that, in general, this approach requires far too much semantic overload on the part of the specification, the implementer, and the content author; I am now opposed to having any properties other than tts:extent and tts:origin have such special semantics, and that allowing these two properties to have special semantics is strictly for the purpose of accommodating a non-compliant, but fielded practice that grew out of a particular implementation; in any case, this proposal (of using an explicit or anonymous set) is not technically required since @condition on <style> achieves the same results;
your 2b variant also requires applying animation effects to <style> elements, which I believe significantly complicates the specification, implementation and authoring without any technical benefit not supported by the direct use of @condition on a content element or on an explicit animation element;

My conclusion is that no new technical mechanism is required, and that this issue can be fully resolved by adding clarifications to the effect:

@condition never causes an element to not be parsed or not appear in reduced infoset;
@condition on style when evaluated to false means that the styles specified on that style are not added to a related specified style set, but chained styling is not affected, i.e., chains aren't broken;
information about evaluation time of condition expressions needs to be added.

I will post a PR that adds such clarifying language.

…me (#128).

nigelmegitt · 2017-05-31T07:47:09Z

OK I can accept not adding set to style, but I see also that the region element permits condition. Since the region attribute can only reference a single region, and there is no chaining of regions, what region applies to an element that specifies a region whose condition evaluates to false?

skynavga · 2017-05-31T08:21:15Z

On Wed, May 31, 2017 at 1:47 AM, Nigel Megitt ***@***.***> wrote: OK I can accept not adding set to style, but I see also that the region element permits condition. Since the region attribute can only reference a single region, and there is no chaining of regions, what region applies to an element that specifies a region whose condition evaluates to false?

Multiple conditional explicit inline regions can be specified where the first one whose condition is not false gets used. Same for walking up the hierarchy to find first ancestor whose conditionalized region is not false.

…

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#128 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXCb-hb_SlOVcnxvNFwi0ad8JNbs-n5ks5r_Rr9gaJpZM4GcAlv> .

nigelmegitt · 2017-05-31T09:10:40Z

Multiple conditional explicit inline regions can be specified where the
first one whose condition is not false gets used.

I think that's too limiting and syntactically awkward - we should be able to use referential region specification too, but are blocked by this part of the spec:

If specified, the value of a region attribute must adhere to the IDREF data type

The easiest (!) solution seems to be to change this to IDREFS and resolve the computed value to the first listed region whose condition resolves to true.

skynavga changed the title ~~xml:id uniqueness needs to be broken for some uses of condition~~ The uniqueness of xml:id needs to be broken for some uses of condition Sep 10, 2016

nigelmegitt mentioned this issue Sep 20, 2016

Make inline region semantics set values on current region #168

Closed

skynavga modified the milestone: TTML2WR Feb 23, 2017

palemieux assigned palemieux and nigelmegitt and unassigned palemieux May 4, 2017

skynavga self-assigned this May 13, 2017

skynavga removed their assignment May 15, 2017

skynavga modified the milestone: Editor's WR Work List May 29, 2017

skynavga assigned skynavga and unassigned nigelmegitt May 29, 2017

skynavga changed the title ~~The uniqueness of xml:id needs to be broken for some uses of condition~~ Support for conditional styling. May 29, 2017

skynavga added the question label May 29, 2017

skynavga added a commit that referenced this issue May 30, 2017

Elaborate semantics of conditionalized styling, specify evaluation ti…

1f9c8ff

…me (#128).

skynavga mentioned this issue May 30, 2017

Issue 0128 conditional styling #347

Merged

skynavga added enhancement pr open and removed question labels May 30, 2017

skynavga closed this as completed in #347 Jun 3, 2017

skynavga added pr merged and removed pr open labels Jun 3, 2017

skynavga removed their assignment Dec 25, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support for conditional styling. #128

Support for conditional styling. #128

plehegar commented Nov 4, 2015

skynavga commented Sep 10, 2016

nigelmegitt commented Sep 10, 2016

nigelmegitt commented Sep 20, 2016

palemieux commented May 4, 2017

skynavga commented May 11, 2017

nigelmegitt commented May 14, 2017

palemieux commented May 15, 2017

nigelmegitt commented May 15, 2017

skynavga commented May 15, 2017 via email

nigelmegitt commented May 15, 2017

skynavga commented May 15, 2017 via email

palemieux commented May 18, 2017

skynavga commented May 18, 2017 •

edited

nigelmegitt commented May 18, 2017

skynavga commented May 18, 2017

nigelmegitt commented May 19, 2017

skynavga commented May 19, 2017 •

edited

nigelmegitt commented May 19, 2017 •

edited

skynavga commented May 19, 2017

nigelmegitt commented May 19, 2017

skynavga commented May 19, 2017 •

edited

nigelmegitt commented May 19, 2017

skynavga commented May 29, 2017

skynavga commented May 30, 2017 •

edited

nigelmegitt commented May 31, 2017

skynavga commented May 31, 2017 via email

nigelmegitt commented May 31, 2017

Support for conditional styling. #128

Support for conditional styling. #128

Comments

plehegar commented Nov 4, 2015

skynavga commented Sep 10, 2016

nigelmegitt commented Sep 10, 2016

nigelmegitt commented Sep 20, 2016

palemieux commented May 4, 2017

skynavga commented May 11, 2017

nigelmegitt commented May 14, 2017

Possible approaches

1. Chained referential styling

2a. Conditional anonymous set elements

2b. Styles reference set elements using the animate attribute.

My preferred choice

palemieux commented May 15, 2017

nigelmegitt commented May 15, 2017

skynavga commented May 15, 2017 via email

nigelmegitt commented May 15, 2017

skynavga commented May 15, 2017 via email

palemieux commented May 18, 2017

skynavga commented May 18, 2017 • edited

nigelmegitt commented May 18, 2017

skynavga commented May 18, 2017

nigelmegitt commented May 19, 2017

skynavga commented May 19, 2017 • edited

nigelmegitt commented May 19, 2017 • edited

skynavga commented May 19, 2017

nigelmegitt commented May 19, 2017

skynavga commented May 19, 2017 • edited

nigelmegitt commented May 19, 2017

skynavga commented May 29, 2017

skynavga commented May 30, 2017 • edited

nigelmegitt commented May 31, 2017

skynavga commented May 31, 2017 via email

nigelmegitt commented May 31, 2017

2a. Conditional anonymous `set` elements

2b. Styles reference `set` elements using the `animate` attribute.

skynavga commented May 18, 2017 •

edited

skynavga commented May 19, 2017 •

edited

nigelmegitt commented May 19, 2017 •

edited

skynavga commented May 19, 2017 •

edited

skynavga commented May 30, 2017 •

edited