Re: <initial> vs inherited

I've not seen any movement on this topic in the issues or in the meeting
notes.
Are we happy/content with <initial> or should we add this to next week's
agenda?

-Dae

*Dae Kim | Video Engineer | Encoding Technology*
*9420 94f4 a834 b038 2920 34b3 38ad b632 3738 942c 942f*

On Wed, Feb 3, 2016 at 7:55 AM, Glenn Adams <glenn@skynav.com> wrote:

>
>
> On Wed, Feb 3, 2016 at 3:12 AM, John Birch <John.Birch@screensystems.tv>
> wrote:
>
>> This is probably a silly question…. But would it be feasible to have an
>> *optional* ‘container’ element in TTML2 for multiple region definitions
>> within which you can set style(s) that would then be inherited /inheritable
>> by any child region elements?
>>
>
> the layout element could potentially be used, but we decided a while back
> to use root (tt) instead to manage inheritance by region; see [1]; of
> course this is a TTML2 only feature
>
> [1]
> https://rawgit.com/w3c/ttml2/master/spec/ttml2.html#semantics-style-inheritance-root
>
>
>>
>>
>> e.g.
>>
>>
>>
>> <style xml:id="initialStyle" tts:color="white"
>> tts:fontFamily="monospaceSerif" tts:textAlign="start" etc…/>
>>
>>
>>
>> <regions style =”initialStyle”>
>>
>> <region xml:id="r1">
>>
>>   <style tts:color="green"/>
>>
>>   <style tts:textAlign="center"/>
>>
>> </region>
>>
>> <region xml:id="r2">
>>
>>   <style tts:color="yellow"/>
>>
>>   <style tts:textAlign="center"/>
>>
>> </region>
>>
>> </regions>
>>
>>
>>
>> Of course such a TTML2 document could not be processed correctly by a
>> TTML1 processor, but could be down converted by repeating the initial style
>> values into each region definition.
>>
>>
>>
>> Alternatively, what about allowing chained referential regions… so the
>> initial values are set in a region (probably one that is not referenced
>> directly by content) that is then referenced by other region definitions.
>>
>
> regions in TTML{1,2} can freely make use of the @style attribute to
> referenced defined styles including chained styles
>
>
>>
>>
>> Like I said, probably silly ideas but just wondering what’s possible.
>>
>>
>>
>> Best regards,
>>
>> John
>>
>>
>>
>>
>> *John Birch | Strategic Partnerships Manager | Screen *Main Line : +44
>> 1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532
>> Mobile : +44 7919 558380 | Fax : +44 1473 830078
>> John.Birch@screensystems.tv | www.screensystems.tv |
>> https://twitter.com/screensystems
>>
>>
>> *Visit us at BVE, London Excel, 23-25 February 2016, stand C20*
>>
>> *P* *Before printing, think about the environment*
>>
>> *From:* Glenn Adams [mailto:glenn@skynav.com]
>> *Sent:* 03 February 2016 06:37
>> *To:* Pierre-Anthony Lemieux
>> *Cc:* Dae Kim; Nigel Megitt; TTWG
>> *Subject:* Re: <initial> vs inherited
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Feb 2, 2016 at 10:58 PM, Pierre-Anthony Lemieux <pal@sandflow.com>
>> wrote:
>>
>> Hi Glenn,
>>
>> > firstly, this question is well formed only with respect to inheritable
>> properties; it doesn't apply to non-inheritable properties;
>>
>> Oh. I was thinking of using chained referential styling, i.e. define a
>> style element with desired 'initial' values
>>
>> <style xml:id="s1" tts:color="white" tts:fontFamily="monospaceSerif"/>
>>
>> and reference the style in all other styles, e.g.
>>
>> <style xml:id="s2" style="s1" tts:color="yellow"/>
>>
>> Why would that not work?
>>
>>
>>
>> sure, that is possible, but that isn't using inheritance or initial value
>> overrides per se; use of @style is just a shorthand for direct (inline)
>> specification of styles on a given element;
>>
>>
>> TTML1 states: "The use of chained referential styling encourages the
>> grouping of style specifications into general and specific sets, which
>> further aids in style specification reuse."
>>
>> >  which effectively applies to all content that may be rendered in any
>> region; however, this would not be a viable
>> > strategy for an inheritable property that to both region and body, such
>> as tts:visible: it is only viable for an inheritable
>> > property that applies to body or a descendant of body and does not
>> apply to region, e.g., tts:color;
>>
>> Ah. An inheritable property applies to descendants in the document
>> structure, and would not apply to a region into which one of these
>> descendants flows. Is that right?
>>
>>
>>
>> whether a style property applies to a given element is independent of
>> whether it is inheritable or not; each property specifies which elements it
>> applies to (semantically) and whether it is inheritable or not;
>>
>>
>>
>> tts:visible happens to be the only inheritable property that applies both
>> to region and content elements
>>
>>
>>
>>
>> > tts:backgroundColor
>>
>> Why is backgroundColor not inheritable, whereas color is, BTW?
>>
>>
>>
>> well, it is not inheritable in XSL-FO or CSS, so that is one explanation;
>> see [1] for some specifics
>>
>>
>>
>> [1]
>> https://www.w3.org/wiki/Inheritance_and_cascade#Why_inheritance_is_useful
>>
>>
>>
>>
>> I am pretty sure it was discussed 10 years ago, but I was not present :)
>>
>>
>>
>> actually it wasn't; we simply adopted the XSL-FO semantics which adopted
>> the CSS2 semantics
>>
>>
>>
>>
>> Best,
>>
>> -- Pierre
>>
>>
>> On Tue, Feb 2, 2016 at 8:26 PM, Glenn Adams <glenn@skynav.com> wrote:
>> >
>> >
>> > On Tue, Feb 2, 2016 at 6:13 PM, Pierre-Anthony Lemieux <
>> pal@sandflow.com>
>> > wrote:
>> >>
>> >> Hi Glenn,
>> >>
>> >> Ok. What is the downside of using style inheritance to avoid having to
>> >> set a property explicitly throughout the document, i.e. have all
>> >> styles derive from a top-level style that overrides the initial
>> >> values?
>> >
>> >
>> > firstly, this question is well formed only with respect to inheritable
>> > properties; it doesn't apply to non-inheritable properties;
>> >
>> > so, for an inheritable property, in TTML1, the only option is to
>> specify the
>> > property on the top-most inheritable element, namely, on region; so,
>> e.g.,
>> >
>> > <region tts:color='yellow'/>
>> >
>> > however, if there are multiple regions, one would be forced to specify
>> this
>> > on each region in turn; alternatively, one might specify:
>> >
>> > <body tts:color='yellow'>...</body>
>> >
>> > which effectively applies to all content that may be rendered in any
>> region;
>> > however, this would not be a viable strategy for an inheritable property
>> > that to both region and body, such as tts:visible: it is only viable
>> for an
>> > inheritable property that applies to body or a descendant of body and
>> does
>> > not apply to region, e.g., tts:color;
>> >
>> > in contrast, in TTML2, again for inheritable properties only, we have
>> the
>> > option of either specifying the property on (1) the top-most inheritable
>> > element, namely, on tt, or on (2) an initial element, which has the
>> effect
>> > of overriding the initial value applied to the top-most inheritable
>> element;
>> >
>> >
>> >>
>> >>
>> >> Best,
>> >>
>> >> -- Pierre
>> >>
>> >> On Tue, Feb 2, 2016 at 1:08 PM, Glenn Adams <glenn@skynav.com> wrote:
>> >> >
>> >> >
>> >> > On Tue, Feb 2, 2016 at 1:27 PM, Pierre-Anthony Lemieux
>> >> > <pal@sandflow.com>
>> >> > wrote:
>> >> >>
>> >> >> Hi Glenn,
>> >> >>
>> >> >> Ok. What approach does XSL-FO and/or CSS take to allowing authors to
>> >> >> avoid having to explicitly set a property through the document?
>> >> >
>> >> >
>> >> > For non-inheritable properties, there is no mechanism other than
>> direct
>> >> > specification (XSL-FO) or a style rule or style attribute (CSS).
>> Also,
>> >> > initial values (for inheritable and non-inheritable properties)
>> cannot
>> >> > be
>> >> > overridden in either XSL-FO or CSS, so defining an initial element
>> for
>> >> > this
>> >> > purpose in TTML2 is effectively a new mechanism not found in either
>> >> > XSL-FO
>> >> > or CSS.
>> >> >
>> >> >>
>> >> >>
>> >> >> Thanks,
>> >> >>
>> >> >> -- Pierre
>> >> >>
>> >> >> On Tue, Feb 2, 2016 at 11:55 AM, Glenn Adams <glenn@skynav.com>
>> wrote:
>> >> >> > Because that is not how the semantics of styles in XSL-FO or CSS
>> >> >> > work,
>> >> >> > and
>> >> >> > thus not how the semantics work in TTML (of any flavor).
>> >> >> >
>> >> >> > Specifying a non-inheritable property on an element to which that
>> >> >> > property
>> >> >> > does not apply is a NO-OP.
>> >> >> >
>> >> >> > In TTML1 we have the following (Section 8.2):
>> >> >> >
>> >> >> > Note:
>> >> >> >
>> >> >> > Due to the general syntax of this specification (and the schemas
>> it
>> >> >> > references) with respect to how style attributes are specified,
>> >> >> > particularly
>> >> >> > for the purpose of supporting inheritance, it is possible for an
>> >> >> > author
>> >> >> > to
>> >> >> > inadvertently specify a non-inheritable style attribute on an
>> element
>> >> >> > that
>> >> >> > applies neither to that element or any of its descendants while
>> still
>> >> >> > remaining conformant from a content validity perspective. Content
>> >> >> > authors
>> >> >> > may wish to make use of TTML content verification tools that
>> detect
>> >> >> > and
>> >> >> > warn
>> >> >> > about such usage.
>> >> >> >
>> >> >> > In TTML2 we promoted this to normative language (Section 10.2):
>> >> >> >
>> >> >> > Unless explicitly permitted by an element type definition, an
>> >> >> > attribute
>> >> >> > in
>> >> >> > the TT Style Namespace should not be specified on an element
>> unless
>> >> >> > it
>> >> >> > either applies to that element or denotes an inheritable style
>> >> >> > property.
>> >> >> > If
>> >> >> > it does not apply to that element and does not denote an
>> inheritable
>> >> >> > style
>> >> >> > property, then it must be ignored for the purpose of
>> non-validation
>> >> >> > processing. In the case of validation processing, such usage
>> should
>> >> >> > be
>> >> >> > reported as a warning, or, if strict validation is performed, as
>> an
>> >> >> > error.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > On Tue, Feb 2, 2016 at 12:48 PM, Pierre-Anthony Lemieux
>> >> >> > <pal@sandflow.com>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> Hi Glenn,
>> >> >> >>
>> >> >> >> > tts:backgroundColor
>> >> >> >>
>> >> >> >> Can you remind us why specifying tts:backgroundColor="X" on <tt>
>> >> >> >> could
>> >> >> >> not mean "set initial value of tts:backgroundColor to X"?
>> >> >> >>
>> >> >> >> Best,
>> >> >> >>
>> >> >> >> -- Pierre
>> >> >> >>
>> >> >> >> On Tue, Feb 2, 2016 at 11:42 AM, Glenn Adams <glenn@skynav.com>
>> >> >> >> wrote:
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On Tue, Feb 2, 2016 at 12:28 PM, Pierre-Anthony Lemieux
>> >> >> >> > <pal@sandflow.com>
>> >> >> >> > wrote:
>> >> >> >> >>
>> >> >> >> >> Hi Glenn et al.,
>> >> >> >> >>
>> >> >> >> >> >Perhaps we need to review
>> >> >> >> >> > uninheritable properties in TTML2 to determine if we need to
>> >> >> >> >> > upgrade
>> >> >> >> >> > them to
>> >> >> >> >> > inheritable,
>> >> >> >> >>
>> >> >> >> >> I like the idea of having a single mechanism for setting an
>> >> >> >> >> initial
>> >> >> >> >> value for properties, i.e. avoid having to set a property
>> >> >> >> >> explicitly
>> >> >> >> >> throughout the document.
>> >> >> >> >>
>> >> >> >> >> Expanding inheritance (instead of introducing a new <initial>
>> >> >> >> >> element)
>> >> >> >> >> seems promising, and intuitive.
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > That won't be sufficient, since we will not be able to make
>> >> >> >> > everything
>> >> >> >> > inherit. The reason for this is related to the semantics of
>> >> >> >> > specific
>> >> >> >> > style
>> >> >> >> > properties. For example, the following cannot inherit:
>> >> >> >> >
>> >> >> >> > tts:backgroundColor
>> >> >> >> > tts:backgroundImage
>> >> >> >> > tts:backgroundPosition
>> >> >> >> > tts:backgroundRepeat
>> >> >> >> > tts:border
>> >> >> >> > tts:bpd
>> >> >> >> > tts:display
>> >> >> >> > tts:extent
>> >> >> >> > tts:ipd
>> >> >> >> > tts:opacity
>> >> >> >> > tts:origin
>> >> >> >> > tts:overflow
>> >> >> >> > tts:padding
>> >> >> >> > tts:position
>> >> >> >> > tts:ruby
>> >> >> >> > tts:unicodeBidi
>> >> >> >> > tts:writingMode
>> >> >> >> > tts:zIndex
>> >> >> >> >
>> >> >> >> > Possible candidates for upgrading to inheritable are:
>> >> >> >> >
>> >> >> >> > tts:displayAlign
>> >> >> >> > tts:showBackground
>> >> >> >> >
>> >> >> >> > So really, only these two are potentially able to be recast as
>> >> >> >> > inheritable
>> >> >> >> > in TTML2. All the rest (above) rely on initial value, and, for
>> >> >> >> > that
>> >> >> >> > matter,
>> >> >> >> > initial value also applies to inheritable properties at the
>> top of
>> >> >> >> > the
>> >> >> >> > inheritance tree (region in TTML1, tt in TTML2).
>> >> >> >> >
>> >> >> >> > The initial element is already written into the TTML2 spec,
>> >> >> >> > implemented,
>> >> >> >> > deployed, and previously discussed in the WG (though perhaps we
>> >> >> >> > didn't
>> >> >> >> > dive
>> >> >> >> > in too deeply).
>> >> >> >> >
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> > though doing so will require careful consideration of
>> >> >> >> >> > interoperability with TTML1 behavior.
>> >> >> >> >>
>> >> >> >> >> I see two scenarios:
>> >> >> >> >>
>> >> >> >> >> - an author wishes to create a document that conforms to both
>> >> >> >> >> TTML1
>> >> >> >> >> and TTML2, in which case the author should set the property
>> >> >> >> >> explicitly
>> >> >> >> >> throughout the document -- this is always safe.
>> >> >> >> >>
>> >> >> >> >> - an author wishes to target only TTML2 processors, in which
>> the
>> >> >> >> >> author can rely on the expanded inheritance rules
>> >> >> >> >>
>> >> >> >> >> Are there other scenarios?
>> >> >> >> >>
>> >> >> >> >> Best,
>> >> >> >> >>
>> >> >> >> >> -- Pierre
>> >> >> >> >>
>> >> >> >> >> On Fri, Jan 29, 2016 at 9:33 AM, Glenn Adams <
>> glenn@skynav.com>
>> >> >> >> >> wrote:
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> > On Fri, Jan 29, 2016 at 10:26 AM, Pierre-Anthony Lemieux
>> >> >> >> >> > <pal@sandflow.com>
>> >> >> >> >> > wrote:
>> >> >> >> >> >>
>> >> >> >> >> >> Hi Glenn,
>> >> >> >> >> >>
>> >> >> >> >> >> > This could also be done in other ways, such as by
>> specifying
>> >> >> >> >> >> > these
>> >> >> >> >> >> > properties on the tt element,
>> >> >> >> >> >> > from which all inheritance would occur (in TTML2);
>> however,
>> >> >> >> >> >> > that
>> >> >> >> >> >> > wouldn't work for properties
>> >> >> >> >> >> > that don't inherit, like tts:showBackground, etc.
>> >> >> >> >> >>
>> >> >> >> >> >> Why doesn't tts:showBackground inherit?
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> > It was originally defined on region in TTML1, which has no
>> way
>> >> >> >> >> > for
>> >> >> >> >> > a
>> >> >> >> >> > region
>> >> >> >> >> > to inherit. However, we are adding root element inheritance
>> in
>> >> >> >> >> > TTML2
>> >> >> >> >> > (e.g.,
>> >> >> >> >> > from tt to head to layout to region). Perhaps we need to
>> review
>> >> >> >> >> > uninheritable properties in TTML2 to determine if we need to
>> >> >> >> >> > upgrade
>> >> >> >> >> > them to
>> >> >> >> >> > inheritable, though doing so will require careful
>> consideration
>> >> >> >> >> > of
>> >> >> >> >> > interoperability with TTML1 behavior.
>> >> >> >> >> >
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >> Thanks,
>> >> >> >> >> >>
>> >> >> >> >> >> -- Pierre
>> >> >> >> >> >>
>> >> >> >> >> >> On Fri, Jan 29, 2016 at 9:11 AM, Glenn Adams
>> >> >> >> >> >> <glenn@skynav.com>
>> >> >> >> >> >> wrote:
>> >> >> >> >> >> > I can provide some respond to this.
>> >> >> >> >> >> >
>> >> >> >> >> >> > On Fri, Jan 29, 2016 at 8:14 AM, Pierre-Anthony Lemieux
>> >> >> >> >> >> > <pal@sandflow.com>
>> >> >> >> >> >> > wrote:
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> Hi Dae,
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> > initial
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> How does Netflix plan to use <initial>?
>> >> >> >> >> >> >
>> >> >> >> >> >> >
>> >> >> >> >> >> > The TTT tools already support the initial element with
>> the
>> >> >> >> >> >> > ttml2
>> >> >> >> >> >> > model,
>> >> >> >> >> >> > and
>> >> >> >> >> >> > has found it to be very useful in specifying a variety of
>> >> >> >> >> >> > non-default,
>> >> >> >> >> >> > global style settings, such as default color and font
>> >> >> >> >> >> > related
>> >> >> >> >> >> > properties,
>> >> >> >> >> >> > etc.
>> >> >> >> >> >> >
>> >> >> >> >> >> > For example, the CAP2TT tool in TTT specifies a test
>> >> >> >> >> >> > configuration
>> >> >> >> >> >> > file
>> >> >> >> >> >> > that
>> >> >> >> >> >> > specifies a template for generating TTML2 output files in
>> >> >> >> >> >> > which
>> >> >> >> >> >> > is
>> >> >> >> >> >> > specified
>> >> >> >> >> >> > the following:
>> >> >> >> >> >> >
>> >> >> >> >> >> > <initial tts:fontSize="4vh"/>
>> >> >> >> >> >> > <initial tts:lineHeight="5vh"/>
>> >> >> >> >> >> > <initial tts:showBackground="whenActive"/>
>> >> >> >> >> >> >
>> >> >> >> >> >> > Here, initial is used to alter the default initial value.
>> >> >> >> >> >> > This
>> >> >> >> >> >> > could
>> >> >> >> >> >> > also be
>> >> >> >> >> >> > done in other ways, such as by specifying these
>> properties
>> >> >> >> >> >> > on
>> >> >> >> >> >> > the
>> >> >> >> >> >> > tt
>> >> >> >> >> >> > element, from which all inheritance would occur (in
>> TTML2);
>> >> >> >> >> >> > however,
>> >> >> >> >> >> > that
>> >> >> >> >> >> > wouldn't work for properties that don't inherit, like
>> >> >> >> >> >> > tts:showBackground,
>> >> >> >> >> >> > etc.
>> >> >> >> >> >> >
>> >> >> >> >> >> > Note that be using initial to specify an explicit
>> >> >> >> >> >> > tts:lineHeight,
>> >> >> >> >> >> > then
>> >> >> >> >> >> > there
>> >> >> >> >> >> > is no possibility of using the default initial value of
>> >> >> >> >> >> > 'normal'
>> >> >> >> >> >> > (which
>> >> >> >> >> >> > has
>> >> >> >> >> >> > been a problem with IMSC content).
>> >> >> >> >> >> >
>> >> >> >> >> >> > It is also useful for redefining the default initial
>> value
>> >> >> >> >> >> > of
>> >> >> >> >> >> > tts:backgroundColor and resolving the platform dependent
>> >> >> >> >> >> > default
>> >> >> >> >> >> > initial
>> >> >> >> >> >> > value of tts:color.
>> >> >> >> >> >> >
>> >> >> >> >> >> >
>> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >
>> >> >> >> >
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >
>> >
>>
>>
>>
>> This message may contain confidential and/or privileged information. If
>> you are not the intended recipient you must not use, copy, disclose or take
>> any action based on this message or any information herein. If you have
>> received this message in error, please advise the sender immediately by
>> reply e-mail and delete this message. Thank you for your cooperation.
>> Screen Subtitling Systems Ltd. Registered in England No. 2596832.
>> Registered Office: The Old Rectory, Claydon Church Lane, Claydon, Ipswich,
>> Suffolk, IP6 0EQ
>>   ­­
>>
>
>