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 Fri, Aug 1, 2014 at 9:59 AM, Glenn Adams <glenn@skynav.com> wrote:

>
>
> On Fri, Aug 1, 2014 at 9:19 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>
> wrote:
>
>>  On 01/08/2014 16:01, "Glenn Adams" <glenn@skynav.com> wrote:
>>
>>
>> On Fri, Aug 1, 2014 at 7:51 AM, Timed Text Working Group Issue Tracker <
>> 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.
>
>
>>  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.


>
>
>>
>>      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.
>>> -->
>>>
>>>
>>>
>>>
>>>
>>
>