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

Could you point at or construct a real world example, i.e., images of what
a mixture of forced and non-forced content looks like depending on whether
a forced display parameter is true or false?


On Sat, Jun 21, 2014 at 6: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
> >> >> >> >>
> >> >> >> >
> >> >> >
> >> >> >
> >> >
> >> >
> >
> >
>