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

I have confirmed that the intent is tts:visibility="hidden".

Why would this be a problem?

-- Pierre


On Sat, Jun 21, 2014 at 5:56 PM, Pierre-Anthony Lemieux
<pal@sandflow.com> wrote:
> Hi Glenn,
>
>> why would one want it to occupy layout space if not selected?
>> that doesn't make any sense;
>
> The forced content would have been positioned with the non-forced
> content present. Simply removing the non-forced content from flow
> would potentially change the rendered position of the forced content.
>
> I will confirm this.
>
> Best,
>
> -- Pierre
>
> On Sat, Jun 21, 2014 at 5:50 PM, Glenn Adams <glenn@skynav.com> wrote:
>>
>> On Sat, Jun 21, 2014 at 6:43 PM, Pierre-Anthony Lemieux <pal@sandflow.com>
>> wrote:
>>>
>>> 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".
>>
>>
>> it should; why would one want it to occupy layout space if not selected?
>> that doesn't make any sense;
>>
>> i don't see how to handle conditional content and conditional visibility; i
>> think the best you will get is the former
>>
>>>
>>>
>>> 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 01:32:58 UTC