Re: <initial> vs inherited

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
>   ­­
>