Re: [IMSC] Thoughts re: issue-312 -- itts:forcedDisplay

On Fri, Jun 20, 2014 at 7:05 PM, Pierre-Anthony Lemieux <pal@sandflow.com>
wrote:

> Hi all,
>
> During our last call, I noted two concerns with the itts:forcedDisplay
> feature as currently drafted.
>
> (a) the semantics of the itts:forcedDisplay feature are not
> sufficiently specified
> (b) the representation of itts:forcedDisplay as an attribute is not
> desirable
>

that should read as a *style* *attribute*


>
> To address (a), below is proposed prose:
>
> """
> The presentation processor SHALL accept an optional boolean parameter
> called forcedDisplayModeParameter, whose value may be set by the
> application. If not set, the value of forcedDisplayModeParameter shall
> be assumed to be equal to "false".
>

no, it should not be a parameter, in which it would go into some parameter
namespace, but should be a metadata attribute, ittm:forcedDisplay

i'm not sure why you wish to lengthen the name unnecessarily



>
> If the value of forcedDisplayModeParameter is "true", a content
> element with a itts:forcedDisplay computed value of "false" shall be
> assumed to have a tts:visibility computed value equal to "hidden",
> even if tts:visibility is otherwise set to "true".
> """
>

now, this is again placing style/presentation semantics on this metadata
attribute, which is inapropriate


>
> The idea is to essentially ignore the itts:forcedDisplay attribute
> unless otherwise specifically requested by the application.


i'm not sure what "requested by the application" means here


> This also
> clarifies that itts:forcedDisplay has "no effect on content layout or
> composition, but merely determines whether composed content is visible
> or not."


if that is the purpose, then the tts:visibility property should be used and
therefore there is no need for a new forcedDisplay attribute


> As next step, I plan to create examples.
>
> Re: (b), I am not comfortable rejecting a solution that users have
> devised and implemented based on actual use cases and in the absence
> of specific guidance and/or prohibition in TTML 1.0.
>

if those users expect that the TTWG would simply adopt a solution as a fait
accompli, then they are naive; an appropriate process would have been to
bring use cases and requirements to the TTWG first, not bring a solution as
a given

at this point, I think the best that can be hoped for IMSC is to define a
metadata attribute ittm:forcedDisplay which is described as a hint that the
associated content is intended to be selected as a candidate for display by
a higher level protocol (outside the scope of formally defined TTML
processing); in other words, TTML will remain silent on any presentation
semantics of such an attribute;

on the other hand, we may choose in TTML2 to define a conditional content
mechanism similar to the SMIL or SVG switch element, that could address
this use case


>
> Best,
>
> -- Pierre
>
>