Re: <initial> vs inherited

Frankly, I don't think there is any issue to discuss. However, see comment
below.

On Thu, Mar 31, 2016 at 12:08 PM, Pierre-Anthony Lemieux <pal@sandflow.com>
wrote:

> Hi Dae,
>
> Apologies for not following-up on that thread. My mind has been
> focused on IMSC1 lately. I have the following question based on the
> thread.
>
> > regions in TTML{1,2} can freely make use of the @style attribute to
> referenced defined styles including chained styles
>
> Ok, so what does this not achieve that <initial> achieve in practice?
>

Primarily, initial will be used to change the default initial value of a
non-inheritable property, which includes:

   - tts:backgroundColor
   - tts:backgroundImage
   - tts:backgroundPosition
   - tts:backgroundRepeat
   - tts:border
   - tts:bpd
   - tts:display
   - tts:displayAlign
   - tts:extent
   - tts:ipd
   - tts:opacity
   - tts:origin
   - tts:overflow
   - tts:padding
   - tts:position
   - tts:ruby
   - tts:showBackground
   - tts:unicodeBidi
   - tts:writingMode
   - tts:zIndex

I can think of a use case for wanting to override the default initial value
for most, but not all of these properties.

Secondarily, initial will be used to change the default initial value for
(the remaining) inheritable properties, e.g., tts:color, tts:fontSize,
tts:lineHeight, etc.



>
> Happy to discuss on the call next week.
>
> Best,
>
> -- Pierre
>
> On Thu, Mar 31, 2016 at 11:06 AM, Dae Kim <dakim@netflix.com> wrote:
> > 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
> >>>   ­­
> >>
> >>
> >
>