Re: <initial> vs inherited

Okay, I see your point Glenn – there's only one initial value per style attribute and scoping functionality can be placed elsewhere – though this to me feels like it could be a syntactically complex way to achieve declarative styling.

I think it's important to consider the styling syntax and semantics overall, not just <initial> in isolation. In TTML1 we have an applicative model in which styles can be applied by reference or inline, and there's nothing to prevent the definition of an "initial" style (e.g. with xml:id="initial") that is then referenced by all the other styles:

<style xml:id="initial" tts:backgroundColor="black"/>
<style xml:id="style1" style="initial" tts:color="white/>

It's not clear that a new element adds any functionality that can't be achieved this way already.

Some wider context that seems relevant at least to me:
* We intend to consider how TTML works in relation to HTML/CSS
* Model for binding presentation values to externally defined parameters <https://github.com/w3c/ttml2/issues/149>
* Style set resolution support for root inheritance. <https://github.com/w3c/ttml2/issues/145>
* xml:id uniqueness needs to be broken for some uses of condition<https://github.com/w3c/ttml2/issues/128>
* Define HTML5 Mapping<https://github.com/w3c/ttml2/issues/127>
* The inclusion of xlink support in TTML2

Adding the concept of an <initial> element looks like a partial solution to a bigger set of problems.

We should also consider:
* allowing inclusion of external styling resource(s) using xlink
* the context of conversion of an ISD into a fragment of HTML/CSS for presentation and how we can tunnel class attribute values into that fragment for the purpose of downstream style modification (e.g. by adding the class attribute to body/div/p/span even if it's ignored for TTML processing purposes)
* whether we actually would benefit from any kind of declarative styling to use such a class attribute or other mechanisms (e.g. to conditionalize styling using XPath expressions)
* if we want a migration path to using CSS style attributes where there's semantic equivalence, e.g. defining how an external CSS stylesheet can be converted into TTML styles
* what is the priority ordering of styles (i.e. how the style resolution process should incorporate any agreed additional functionality)



From: Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>>
Date: Tuesday, 5 April 2016 18:50
To: Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>>
Cc: TTWG <public-tt@w3.org<mailto:public-tt@w3.org>>, Pierre-Anthony Lemieux <pal@sandflow.com<mailto:pal@sandflow.com>>, Dae Kim <dakim@netflix.com<mailto:dakim@netflix.com>>, John Birch <John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv>>
Subject: 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<mailto: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 <tel:+44%C2%A03030807996> (0)3030807996<tel:+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<mailto: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<mailto: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<mailto: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<mailto:glenn@skynav.com>> wrote:
>>
>>
>>
>> On Wed, Feb 3, 2016 at 3:12 AM, John Birch <John.Birch@screensystems.tv<mailto: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<tel:%2B44%201473%20831700> | Ext : 2208 | Direct Dial : +44 1473 834532<tel:%2B44%201473%20834532>
>>> Mobile : +44 7919 558380<tel:%2B44%207919%20558380> | Fax : +44 1473 830078<tel:%2B44%201473%20830078>
>>> 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<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
>>>   ­­
>>
>>
>