RE: <initial> vs inherited

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?

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.

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<mailto:John.Birch@screensystems.tv> | www.screensystems.tv<http://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<mailto: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<mailto:glenn@skynav.com>> wrote:
>
>
> On Tue, Feb 2, 2016 at 6:13 PM, Pierre-Anthony Lemieux <pal@sandflow.com<mailto: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<mailto:glenn@skynav.com>> wrote:
>> >
>> >
>> > On Tue, Feb 2, 2016 at 1:27 PM, Pierre-Anthony Lemieux
>> > <pal@sandflow.com<mailto: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<mailto: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<mailto: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<mailto:glenn@skynav.com>>
>> >> >> wrote:
>> >> >> >
>> >> >> >
>> >> >> > On Tue, Feb 2, 2016 at 12:28 PM, Pierre-Anthony Lemieux
>> >> >> > <pal@sandflow.com<mailto: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<mailto:glenn@skynav.com>>
>> >> >> >> wrote:
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On Fri, Jan 29, 2016 at 10:26 AM, Pierre-Anthony Lemieux
>> >> >> >> > <pal@sandflow.com<mailto: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<mailto: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<mailto: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