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

Hi Glenn,

Thanks for these initial thoughts.

> 3. evaluating this sub-tree in a postorder traversal, prune elements
> if they are not a content element, if they have a condition attribute that evaluates to false,

"Forced" does not remove the content element from layout and flow, but instead
effectively sets the visibility to zero, like tts:visibility="hidden".

Best,

-- Pierre

On Sat, Jun 21, 2014 at 5:38 PM, Glenn Adams <glenn@skynav.com> wrote:
>
>
> On Sat, Jun 21, 2014 at 6:07 PM, Pierre-Anthony Lemieux <pal@sandflow.com>
> wrote:
>>
>> > What do you mean by "application" in this context?
>>
>> The entity that is instructing the presentation processor to render
>> the IMSC document.
>>
>> > I also don't know what parameter means in this context,
>> > e.g., what does it mean vis-a-vis a TTML parameter, i.e.,
>> > an attribute expressing a TTML parameter.
>>
>> It is not a TTML parameter, as in a ttp:*, but instead a state
>> variable passed to the presentation processor instructing it to render
>> or not non-forced content, like a function argument in a procedural
>> language.
>>
>> > I am opposed to a one-off solution to a special case of the conditional
>> >  content problem. And the forcedDisplay feature is exactly such a
>> > special case.
>>
>> Can you think of a generic solution that would reduce to a single
>> attribute controlling the rendering of forced content? If so, we could
>> consider using it in IMSC.
>
>
> I haven't given it much thought, but if we were to introduce as the general
> mechanism a new element type:
>
> <tt:switch condition="expression">
> ... content elements ...
> </tt:switch>
>
> then we could also, or as an alternative, introduce an attribute @condition
> on content element vocabulary, e.g.,
>
> <div condition="expression"/>
>
> where expression uses a simple expression language such as media queries
> level 4 [1] or a derivative.
>
> [1] http://dev.w3.org/csswg/mediaqueries4/
>
> For example,
>
> <p condition="(forced)"/>
>
> <p condition="not (forced)"/>
>
> <p condition="(locale: en)"/>
>
> <p condition="not (locale: en)"/>
>
> <p condition="(forced) or not (locale: en)"/>
>
> ...
>
> Where the semantics of @condition is essentially changing step 3 of 9.3.3
> [construct intermediate document] to read essentially as follows:
>
> 3. evaluating this sub-tree in a postorder traversal, prune elements if they
> are not a content element, if they have a condition attribute that evaluates
> to false, if they are temporally inactive, if they are empty, or if they
> aren't associated with region R according to the [associate region]
> procedure;
>
>>
>>
>> Thanks,
>>
>> -- Pierre
>>
>> On Fri, Jun 20, 2014 at 10:56 PM, Glenn Adams <glenn@skynav.com> wrote:
>> >
>> > On Fri, Jun 20, 2014 at 10:33 PM, Pierre-Anthony Lemieux
>> > <pal@sandflow.com>
>> > wrote:
>> >>
>> >> Hi Glenn,
>> >>
>> >> Thanks for the feedback.
>> >>
>> >> > no, [forcedDisplayModeParameter] should not be a parameter, in which
>> >> > it would go into some
>> >> > parameter namespace, but should be a metadata attribute,
>> >> > ittm:forcedDisplay
>> >>
>> >> forcedDisplayModeParameter != itts:forcedDisplay.
>> >> forcedDisplayModeParameter would be a parameter passed by the
>> >> application to the processor, not a parameter within the document.
>> >
>> >
>> > What do you mean by "application" in this context? I also don't know
>> > what
>> > parameter means in this context, e.g., what does it mean vis-a-vis a
>> > TTML
>> > parameter, i.e., an attribute expressing a TTML parameter.
>> >
>> >>
>> >>
>> >> > in other words, TTML will remain silent on any presentation semantics
>> >> > of
>> >> > such an attribute;
>> >>
>> >> How would interoperability be achieved?
>> >
>> >
>> > By defining a standard mechanism for expressing conditional content
>> > contingent on external processor state, e.g., selected language, whether
>> > display of some content is forced or not, etc.
>> >
>> > I am opposed to a one-off solution to a special case of the conditional
>> > content problem. And the forcedDisplay feature is exactly such a special
>> > case.
>> >
>> >>
>> >>
>> >> Thanks,
>> >>
>> >> -- Pierre
>> >>
>> >> On Fri, Jun 20, 2014 at 8:58 PM, Glenn Adams <glenn@skynav.com> wrote:
>> >> >
>> >> > 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
>> >> >>
>> >> >
>> >
>> >
>
>

Received on Sunday, 22 June 2014 00:44:45 UTC