Re: ISSUE-331 (forcedDisplay region background note): An advisory note on the use of backgrounds on regions in combination with forcedDisplay [TTML IMSC 1.0]

On 01/08/2014 17:11, "Glenn Adams" <glenn@skynav.com<mailto:glenn@skynav.com>> wrote:




On Fri, Aug 1, 2014 at 9:59 AM, Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>> wrote:


On Fri, Aug 1, 2014 at 9:19 AM, Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>> wrote:
On 01/08/2014 16:01, "Glenn Adams" <glenn@skynav.com<mailto:glenn@skynav.com>> wrote:


On Fri, Aug 1, 2014 at 7:51 AM, Timed Text Working Group Issue Tracker <sysbot+tracker@w3.org<mailto:sysbot+tracker@w3.org>> wrote:
ISSUE-331 (forcedDisplay region background note): An advisory note on the use of backgrounds on regions in combination with forcedDisplay [TTML IMSC 1.0]

http://www.w3.org/AudioVideo/TT/tracker/issues/331

Raised by: Nigel Megitt
On product: TTML IMSC 1.0

This issue is created to fulfil Action-314.

Rationale:

Since forcedDisplay affects the computed value of the tts:visibility property

Actually it doesn't change the computed value of tts:visibility (or shouldn't). It qualifies how the computed value is used, e.g., by doing something like:

if (computedValue('tts:visibility') == 'visible') {
  if (!displayForcedOnlyMode || (computedValue('itts:forcedDisplay') != 'false')) {
    renderContent()
  }
}


That would be one way to do it, but the current spec does seem to state that the tts:visibility computed value should change.

Then it needs to be changed.


Aren't they completely equivalent though?

No, since computed values are referenced elsewhere, e.g., inheritance.

This may be one for Pierre: is the intention to override visibility of all descendants regardless of their more local setting of forcedDisplay, or is it desired to allow visible descendants of content elements that are hidden because forcedDisplay is "false"?

<div forcedDisplay="false">
<p>This is hidden.</p>
<p forcedDisplay="true">This is visible.</p>
</div>

Current spec reads to me that the above is allowed and would result in "This is visible." being visible if displayForcedOnlyMode is true, but "This is hidden." being hidden.


I don't see what the difference would be between your algorithm and:

if (!displayForcedOnlyMode || (computedValue('itts:forcedDisplay') !='false')) {
   setComputedValue('tts:visibility', 'visible')
}

if (computedValue('tts:visibility')=='visible') {
   renderContent()
}

The problem is that computed value is referenced elsewhere, and this logic shouldn't impact it.

As another example, we may eventually expose computed values to an app via an OM, in which case the force logic shouldn't impact it.


Does anyone have any plan to expose values via an OM before TTML2? We've already decided to implement conditional display differently in TTML2.



it has no effect on whether or not the hidden/visible content is temporally active. This means that if non-forced content is assigned to a region with a background colour then the background will be shown whenever the content is active even if it is hidden. This is likely to be unexpected behaviour for some readers of the specification, who may imagine that by using a setting of tts:showBackground of "whenActive" they can prevent this effect.

(incidentally they'd be correct in thinking this if forcedDisplay were changed to do what its name suggests and affect tts:display, which arguably would be more useful functionality)

Proposal:

Include a non-normative note such as the following:
<--
NOTE

If the forcedDisplay attribute is used for content in combination with regions that have a non-transparent computed background color then authors should be aware that those regions' backgrounds will be drawn whenever the selected content is active, even if the computed tts:visibility of that content is "none".

Note that the two legal values of tts:visibility are 'visible' and 'hidden'. The values 'none' and 'false' and 'true' are not legal. [IMSC ED currently refers to an illegal value 'true'.

Yes, sorry, my mistake – as Pierre also pointed out I meant "hidden" in place of "none".


BTW, I'd still like to see the name changed to itts:forced in order to avoid the display vs visibility confusion.


I'd like to see it changed to itts:forcedVisibility to make it even clearer, if we're going to change the name at all.


One strategy for avoiding this scenario would be to assign content elements only to regions that have the same value of forcedDisplay.
-->