Re: <initial> vs inherited

On Wed, Apr 6, 2016 at 10:11 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>
wrote:

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

this we cannot do


> ** *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.
>

or a simple solution to a well defined problem; i don't intend to allow the
discussion of initial to turn into an open forum on creating a rich
applicative style system like CSS, and it would be wrong to do so


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

all these are interesting, and I will absolutely object to bundling them in
the discussion of initial


>
>
>
> From: Glenn Adams <glenn@skynav.com>
> Date: Tuesday, 5 April 2016 18:50
> To: Nigel Megitt <nigel.megitt@bbc.co.uk>
> Cc: TTWG <public-tt@w3.org>, Pierre-Anthony Lemieux <pal@sandflow.com>,
> Dae Kim <dakim@netflix.com>, John Birch <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>
> 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
>>> >>>   ­­
>>> >>
>>> >>
>>> >
>>>
>>
>>
>