- From: Pierre-Anthony Lemieux <pal@sandflow.com>
- Date: Fri, 20 Jun 2014 21:33:21 -0700
- To: Glenn Adams <glenn@skynav.com>
- Cc: "public-tt@w3.org" <public-tt@w3.org>
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. > in other words, TTML will remain silent on any presentation semantics of such an attribute; How would interoperability be achieved? 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 Saturday, 21 June 2014 04:34:10 UTC