Re: <initial> vs inherited

The definition of initial value is that it is a constant across all
elements to which the property may apply. Although I can understand the use
case you suggest, initial is not the correct concept to address this case.

I can imagine, however, a use of @condition on a <style> element, where a
new condition predicate function is introduced, such as:

<style xml:id="s1" tts:backgroundColor="green"/>
<style xml:id="s2" condition="element('span')" tts:backgroundColor="red"/>
<style xml:id="conditionalBackground" style="s1 s2"/>


On Tue, Apr 5, 2016 at 8:10 AM, Nigel Megitt <nigel.megitt@bbc.co.uk> wrote:

> I'm happy to add this to the agenda for this week. I don't think we've
> explored this topic enough.
>
> My main query is how/if we scope the elements that we target with initial.
> For example, I would like to be able to specify an initial value of
> backgroundColor on span only, but that is not currently possible.
>
> Nigel
>
> --
>
> *Nigel Megitt*
>
> Executive Product Manager, BBC Design & Engineering
>
> Telephone: +44  <+44%C2%A03030807996>(0)3030807996 <+44%C2%A03030807996>
>
> BC2 C1 Broadcast Centre, Media Village, 201 Wood Lane, London W12 7TP
>
> On 31 Mar 2016, at 20:49, Glenn Adams <glenn@skynav.com> wrote:
>
> 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
>> >>>   ­­
>> >>
>> >>
>> >
>>
>
>