<initial> vs inherited

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

<initial> vs inherited

Pierre-Anthony Lemieux
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.

> 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 <[hidden email]> wrote:

>
>
> On Fri, Jan 29, 2016 at 10:26 AM, Pierre-Anthony Lemieux <[hidden email]>
> 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 <[hidden email]> wrote:
>> > I can provide some respond to this.
>> >
>> > On Fri, Jan 29, 2016 at 8:14 AM, Pierre-Anthony Lemieux
>> > <[hidden email]>
>> > 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.
>> >
>> >
>> >>
>> >>

Reply | Threaded
Open this post in threaded view
|

Re: <initial> vs inherited

Glenn Adams-2


On Tue, Feb 2, 2016 at 12:28 PM, Pierre-Anthony Lemieux <[hidden email]> 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 <[hidden email]> wrote:
>
>
> On Fri, Jan 29, 2016 at 10:26 AM, Pierre-Anthony Lemieux <[hidden email]>
> 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 <[hidden email]> wrote:
>> > I can provide some respond to this.
>> >
>> > On Fri, Jan 29, 2016 at 8:14 AM, Pierre-Anthony Lemieux
>> > <[hidden email]>
>> > 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.
>> >
>> >
>> >>
>> >>

Reply | Threaded
Open this post in threaded view
|

Re: <initial> vs inherited

Pierre-Anthony Lemieux
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 <[hidden email]> wrote:

>
>
> On Tue, Feb 2, 2016 at 12:28 PM, Pierre-Anthony Lemieux <[hidden email]>
> 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 <[hidden email]> wrote:
>> >
>> >
>> > On Fri, Jan 29, 2016 at 10:26 AM, Pierre-Anthony Lemieux
>> > <[hidden email]>
>> > 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 <[hidden email]> wrote:
>> >> > I can provide some respond to this.
>> >> >
>> >> > On Fri, Jan 29, 2016 at 8:14 AM, Pierre-Anthony Lemieux
>> >> > <[hidden email]>
>> >> > 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.
>> >> >
>> >> >
>> >> >>
>> >> >>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: <initial> vs inherited

Glenn Adams-2
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 <[hidden email]> 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 <[hidden email]> wrote:
>
>
> On Tue, Feb 2, 2016 at 12:28 PM, Pierre-Anthony Lemieux <[hidden email]>
> 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 <[hidden email]> wrote:
>> >
>> >
>> > On Fri, Jan 29, 2016 at 10:26 AM, Pierre-Anthony Lemieux
>> > <[hidden email]>
>> > 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 <[hidden email]> wrote:
>> >> > I can provide some respond to this.
>> >> >
>> >> > On Fri, Jan 29, 2016 at 8:14 AM, Pierre-Anthony Lemieux
>> >> > <[hidden email]>
>> >> > 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.
>> >> >
>> >> >
>> >> >>
>> >> >>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: <initial> vs inherited

Pierre-Anthony Lemieux
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?

Thanks,

-- Pierre

On Tue, Feb 2, 2016 at 11:55 AM, Glenn Adams <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> wrote:
>> >
>> >
>> > On Tue, Feb 2, 2016 at 12:28 PM, Pierre-Anthony Lemieux
>> > <[hidden email]>
>> > 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 <[hidden email]> wrote:
>> >> >
>> >> >
>> >> > On Fri, Jan 29, 2016 at 10:26 AM, Pierre-Anthony Lemieux
>> >> > <[hidden email]>
>> >> > 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 <[hidden email]>
>> >> >> wrote:
>> >> >> > I can provide some respond to this.
>> >> >> >
>> >> >> > On Fri, Jan 29, 2016 at 8:14 AM, Pierre-Anthony Lemieux
>> >> >> > <[hidden email]>
>> >> >> > 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.
>> >> >> >
>> >> >> >
>> >> >> >>
>> >> >> >>
>> >
>> >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: <initial> vs inherited

Glenn Adams-2


On Tue, Feb 2, 2016 at 1:27 PM, Pierre-Anthony Lemieux <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> wrote:
>> >
>> >
>> > On Tue, Feb 2, 2016 at 12:28 PM, Pierre-Anthony Lemieux
>> > <[hidden email]>
>> > 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 <[hidden email]> wrote:
>> >> >
>> >> >
>> >> > On Fri, Jan 29, 2016 at 10:26 AM, Pierre-Anthony Lemieux
>> >> > <[hidden email]>
>> >> > 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 <[hidden email]>
>> >> >> wrote:
>> >> >> > I can provide some respond to this.
>> >> >> >
>> >> >> > On Fri, Jan 29, 2016 at 8:14 AM, Pierre-Anthony Lemieux
>> >> >> > <[hidden email]>
>> >> >> > 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.
>> >> >> >
>> >> >> >
>> >> >> >>
>> >> >> >>
>> >
>> >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: <initial> vs inherited

Pierre-Anthony Lemieux
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?

Best,

-- Pierre

On Tue, Feb 2, 2016 at 1:08 PM, Glenn Adams <[hidden email]> wrote:

>
>
> On Tue, Feb 2, 2016 at 1:27 PM, Pierre-Anthony Lemieux <[hidden email]>
> 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 <[hidden email]> 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
>> > <[hidden email]>
>> > 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 <[hidden email]> wrote:
>> >> >
>> >> >
>> >> > On Tue, Feb 2, 2016 at 12:28 PM, Pierre-Anthony Lemieux
>> >> > <[hidden email]>
>> >> > 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 <[hidden email]>
>> >> >> wrote:
>> >> >> >
>> >> >> >
>> >> >> > On Fri, Jan 29, 2016 at 10:26 AM, Pierre-Anthony Lemieux
>> >> >> > <[hidden email]>
>> >> >> > 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 <[hidden email]>
>> >> >> >> wrote:
>> >> >> >> > I can provide some respond to this.
>> >> >> >> >
>> >> >> >> > On Fri, Jan 29, 2016 at 8:14 AM, Pierre-Anthony Lemieux
>> >> >> >> > <[hidden email]>
>> >> >> >> > 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.
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >>
>> >> >> >> >>
>> >> >
>> >> >
>> >
>> >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: <initial> vs inherited

Glenn Adams-2


On Tue, Feb 2, 2016 at 6:13 PM, Pierre-Anthony Lemieux <[hidden email]> 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 <[hidden email]> wrote:
>
>
> On Tue, Feb 2, 2016 at 1:27 PM, Pierre-Anthony Lemieux <[hidden email]>
> 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 <[hidden email]> 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
>> > <[hidden email]>
>> > 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 <[hidden email]> wrote:
>> >> >
>> >> >
>> >> > On Tue, Feb 2, 2016 at 12:28 PM, Pierre-Anthony Lemieux
>> >> > <[hidden email]>
>> >> > 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 <[hidden email]>
>> >> >> wrote:
>> >> >> >
>> >> >> >
>> >> >> > On Fri, Jan 29, 2016 at 10:26 AM, Pierre-Anthony Lemieux
>> >> >> > <[hidden email]>
>> >> >> > 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 <[hidden email]>
>> >> >> >> wrote:
>> >> >> >> > I can provide some respond to this.
>> >> >> >> >
>> >> >> >> > On Fri, Jan 29, 2016 at 8:14 AM, Pierre-Anthony Lemieux
>> >> >> >> > <[hidden email]>
>> >> >> >> > 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.
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >>
>> >> >> >> >>
>> >> >
>> >> >
>> >
>> >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: <initial> vs inherited

Pierre-Anthony Lemieux
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?

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?

> tts:backgroundColor

Why is backgroundColor not inheritable, whereas color is, BTW?

I am pretty sure it was discussed 10 years ago, but I was not present :)

Best,

-- Pierre

On Tue, Feb 2, 2016 at 8:26 PM, Glenn Adams <[hidden email]> wrote:

>
>
> On Tue, Feb 2, 2016 at 6:13 PM, Pierre-Anthony Lemieux <[hidden email]>
> 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 <[hidden email]> wrote:
>> >
>> >
>> > On Tue, Feb 2, 2016 at 1:27 PM, Pierre-Anthony Lemieux
>> > <[hidden email]>
>> > 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 <[hidden email]> 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
>> >> > <[hidden email]>
>> >> > 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 <[hidden email]>
>> >> >> wrote:
>> >> >> >
>> >> >> >
>> >> >> > On Tue, Feb 2, 2016 at 12:28 PM, Pierre-Anthony Lemieux
>> >> >> > <[hidden email]>
>> >> >> > 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 <[hidden email]>
>> >> >> >> wrote:
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On Fri, Jan 29, 2016 at 10:26 AM, Pierre-Anthony Lemieux
>> >> >> >> > <[hidden email]>
>> >> >> >> > 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
>> >> >> >> >> <[hidden email]>
>> >> >> >> >> wrote:
>> >> >> >> >> > I can provide some respond to this.
>> >> >> >> >> >
>> >> >> >> >> > On Fri, Jan 29, 2016 at 8:14 AM, Pierre-Anthony Lemieux
>> >> >> >> >> > <[hidden email]>
>> >> >> >> >> > 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.
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >
>> >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: <initial> vs inherited

Glenn Adams-2


On Tue, Feb 2, 2016 at 10:58 PM, Pierre-Anthony Lemieux <[hidden email]> 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

 

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 <[hidden email]> wrote:
>
>
> On Tue, Feb 2, 2016 at 6:13 PM, Pierre-Anthony Lemieux <[hidden email]>
> 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 <[hidden email]> wrote:
>> >
>> >
>> > On Tue, Feb 2, 2016 at 1:27 PM, Pierre-Anthony Lemieux
>> > <[hidden email]>
>> > 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 <[hidden email]> 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
>> >> > <[hidden email]>
>> >> > 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 <[hidden email]>
>> >> >> wrote:
>> >> >> >
>> >> >> >
>> >> >> > On Tue, Feb 2, 2016 at 12:28 PM, Pierre-Anthony Lemieux
>> >> >> > <[hidden email]>
>> >> >> > 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 <[hidden email]>
>> >> >> >> wrote:
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On Fri, Jan 29, 2016 at 10:26 AM, Pierre-Anthony Lemieux
>> >> >> >> > <[hidden email]>
>> >> >> >> > 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
>> >> >> >> >> <[hidden email]>
>> >> >> >> >> wrote:
>> >> >> >> >> > I can provide some respond to this.
>> >> >> >> >> >
>> >> >> >> >> > On Fri, Jan 29, 2016 at 8:14 AM, Pierre-Anthony Lemieux
>> >> >> >> >> > <[hidden email]>
>> >> >> >> >> > 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.
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >
>> >
>
>

Reply | Threaded
Open this post in threaded view
|

RE: <initial> vs inherited

John Birch-3

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?

 

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.

 

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
[hidden email] | 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:[hidden email]]
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 <[hidden email]> 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

 

 


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 <[hidden email]> wrote:
>
>
> On Tue, Feb 2, 2016 at 6:13 PM, Pierre-Anthony Lemieux <[hidden email]>
> 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 <[hidden email]> wrote:
>> >
>> >
>> > On Tue, Feb 2, 2016 at 1:27 PM, Pierre-Anthony Lemieux
>> > <[hidden email]>
>> > 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 <[hidden email]> 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
>> >> > <[hidden email]>
>> >> > 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 <[hidden email]>
>> >> >> wrote:
>> >> >> >
>> >> >> >
>> >> >> > On Tue, Feb 2, 2016 at 12:28 PM, Pierre-Anthony Lemieux
>> >> >> > <[hidden email]>
>> >> >> > 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 <[hidden email]>
>> >> >> >> wrote:
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On Fri, Jan 29, 2016 at 10:26 AM, Pierre-Anthony Lemieux
>> >> >> >> > <[hidden email]>
>> >> >> >> > 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
>> >> >> >> >> <[hidden email]>
>> >> >> >> >> wrote:
>> >> >> >> >> > I can provide some respond to this.
>> >> >> >> >> >
>> >> >> >> >> > On Fri, Jan 29, 2016 at 8:14 AM, Pierre-Anthony Lemieux
>> >> >> >> >> > <[hidden email]>
>> >> >> >> >> > 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
  ­­  
Reply | Threaded
Open this post in threaded view
|

Re: <initial> vs inherited

nigelmegitt

We already have the layout element – perhaps we could simply permit it to have style attributes that would apply to all regions unless defined otherwise.

E.g.

<layout tts:backgroundColor="black" tts:color="white">
<region xml:id="r1" tts:color="green" tts:origin="…" tts:extent="…" />
<region xml:id="r2" tts:origin="…" tts:extent="…" />
</layout>

r1 would have backgroundColor black and text color green;
r2 would have backgroundColor black and text color white.

One could do a similar thing with <styling> and <style> elements.

The syntactic shorthand of including style attributes directly on the layout or styling elements could be considered synonymous with the inclusion of anonymous style elements as children, i.e. child style elements with no xml:id. I suspect that TTML1 processors would process those elements and ignore them since they are not referenced anywhere.

In other words the above example could be rewritten as:

<layout>
<style tts:backgroundColor="black" tts:color="white">
<region xml:id="r1" tts:color="green" tts:origin="…" tts:extent="…" />
<region xml:id="r2" tts:origin="…" tts:extent="…" />
</layout>

In TTML1 style elements are not permitted as children of the layout element.

In TTML2 right now inherited style attributes are permitted on the tt element to achieve the same effect. I'd like to move them out of the top level element because that would allow us to conditionalise them – this was a point raised back in Santa Clara (or possibly Las Vegas) if I recall correctly (or less correctly).


The discussion of tts:backgroundColor as being not suitable for inheritance may be more easily understood by considering that it causes a background to be painted separately for each of region, div, p and span. Attempting to apply it as a default by inheritance, by applying it to, say, body or region with the intention of using it solely on span would not work – it would have no visible difference to just specifying it on region assuming that the color is not set on any of the elements whose content is flowed into it.

A reasonable use case would be the ability to specify an value of backgroundColor that would apply as the initial value in the context of a restricted set of element types. For example I would like to be able to specify that the initial value of tts:backgroundColor on span is "black" but on all other elements is "transparent". The examples above don't really support that, and the current definition of the initial element doesn't help that either.

Perhaps adding, either to the initial element or an anonymous style element, a "scope" attribute would achieve this, where the attribute could take a list of element types to which those initial styles would apply, i.e. "(region | body | div | p | span | br)*".

Kind regards,

Nigel


From: John Birch <[hidden email]>
Date: Wednesday, 3 February 2016 10:12
To: Glenn Adams <[hidden email]>, Pierre-Anthony Lemieux <[hidden email]>
Cc: Dae Kim <[hidden email]>, Nigel Megitt <[hidden email]>, TTWG <[hidden email]>
Subject: RE: <initial> vs inherited

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?

 

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.

 

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
[hidden email] | www.screensystems.tv | https://twitter.com/screensystems


Visit us at
BVE, London Excel, 23-25 February 2016, stand C20


PBefore printing, think about the environment


From: Glenn Adams [[hidden email]]
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 <[hidden email]> 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

 

 


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 <[hidden email]> wrote:
>
>
> On Tue, Feb 2, 2016 at 6:13 PM, Pierre-Anthony Lemieux <[hidden email]>
> 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 <[hidden email]> wrote:
>> >
>> >
>> > On Tue, Feb 2, 2016 at 1:27 PM, Pierre-Anthony Lemieux
>> > <[hidden email]>
>> > 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 <[hidden email]> 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
>> >> > <[hidden email]>
>> >> > 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 <[hidden email]>
>> >> >> wrote:
>> >> >> >
>> >> >> >
>> >> >> > On Tue, Feb 2, 2016 at 12:28 PM, Pierre-Anthony Lemieux
>> >> >> > <[hidden email]>
>> >> >> > 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 <[hidden email]>
>> >> >> >> wrote:
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On Fri, Jan 29, 2016 at 10:26 AM, Pierre-Anthony Lemieux
>> >> >> >> > <[hidden email]>
>> >> >> >> > 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
>> >> >> >> >> <[hidden email]>
>> >> >> >> >> wrote:
>> >> >> >> >> > I can provide some respond to this.
>> >> >> >> >> >
>> >> >> >> >> > On Fri, Jan 29, 2016 at 8:14 AM, Pierre-Anthony Lemieux
>> >> >> >> >> > <[hidden email]>
>> >> >> >> >> > 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
  ­­  

 

----------------------------

http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------

Reply | Threaded
Open this post in threaded view
|

RE: <initial> vs inherited

John Birch-3

Hi Nigel,

 

Oh yes… that’s much better than introducing a new element!

I’m very conscious that I’m a bit out of the loop and I don’t want to add confusion, but it‘s a very interesting thread and it touches on issues that we (Screen) have encountered with TTML.

 

I’m not sure about the ‘scope’ attribute… but it would seem to solve the problem of concisely only placing a common background behind spans (block boxing).

 

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
[hidden email] | 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: Nigel Megitt [mailto:[hidden email]]
Sent: 03 February 2016 11:30
To: John Birch; Glenn Adams; Pierre-Anthony Lemieux
Cc: Dae Kim; TTWG
Subject: Re: <initial> vs inherited

 

We already have the layout element – perhaps we could simply permit it to have style attributes that would apply to all regions unless defined otherwise.

 

E.g.

 

<layout tts:backgroundColor="black" tts:color="white">

<region xml:id="r1" tts:color="green" tts:origin="…" tts:extent="…" />

<region xml:id="r2" tts:origin="…" tts:extent="…" />

</layout>

 

r1 would have backgroundColor black and text color green;

r2 would have backgroundColor black and text color white.

 

One could do a similar thing with <styling> and <style> elements.

 

The syntactic shorthand of including style attributes directly on the layout or styling elements could be considered synonymous with the inclusion of anonymous style elements as children, i.e. child style elements with no xml:id. I suspect that TTML1 processors would process those elements and ignore them since they are not referenced anywhere.

 

In other words the above example could be rewritten as:

 

<layout>

<style tts:backgroundColor="black" tts:color="white">

<region xml:id="r1" tts:color="green" tts:origin="…" tts:extent="…" />

<region xml:id="r2" tts:origin="…" tts:extent="…" />

</layout>

 

In TTML1 style elements are not permitted as children of the layout element.

 

In TTML2 right now inherited style attributes are permitted on the tt element to achieve the same effect. I'd like to move them out of the top level element because that would allow us to conditionalise them – this was a point raised back in Santa Clara (or possibly Las Vegas) if I recall correctly (or less correctly).

 

 

The discussion of tts:backgroundColor as being not suitable for inheritance may be more easily understood by considering that it causes a background to be painted separately for each of region, div, p and span. Attempting to apply it as a default by inheritance, by applying it to, say, body or region with the intention of using it solely on span would not work – it would have no visible difference to just specifying it on region assuming that the color is not set on any of the elements whose content is flowed into it.

 

A reasonable use case would be the ability to specify an value of backgroundColor that would apply as the initial value in the context of a restricted set of element types. For example I would like to be able to specify that the initial value of tts:backgroundColor on span is "black" but on all other elements is "transparent". The examples above don't really support that, and the current definition of the initial element doesn't help that either.

 

Perhaps adding, either to the initial element or an anonymous style element, a "scope" attribute would achieve this, where the attribute could take a list of element types to which those initial styles would apply, i.e. "(region | body | div | p | span | br)*".

 

Kind regards,

 

Nigel

 

 

From: John Birch <[hidden email]>
Date: Wednesday, 3 February 2016 10:12
To: Glenn Adams <[hidden email]>, Pierre-Anthony Lemieux <[hidden email]>
Cc: Dae Kim <[hidden email]>, Nigel Megitt <[hidden email]>, TTWG <[hidden email]>
Subject: RE: <initial> vs inherited

 

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?

 

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.

 

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
[hidden email] | www.screensystems.tv | https://twitter.com/screensystems

Visit us at
BVE, London Excel, 23-25 February 2016, stand C20


PBefore printing, think about the environment

 

From: Glenn Adams [[hidden email]]
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 <[hidden email]> 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

 

 


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 <[hidden email]> wrote:
>
>
> On Tue, Feb 2, 2016 at 6:13 PM, Pierre-Anthony Lemieux <[hidden email]>
> 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 <[hidden email]> wrote:
>> >
>> >
>> > On Tue, Feb 2, 2016 at 1:27 PM, Pierre-Anthony Lemieux
>> > <[hidden email]>
>> > 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 <[hidden email]> 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
>> >> > <[hidden email]>
>> >> > 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 <[hidden email]>
>> >> >> wrote:
>> >> >> >
>> >> >> >
>> >> >> > On Tue, Feb 2, 2016 at 12:28 PM, Pierre-Anthony Lemieux
>> >> >> > <[hidden email]>
>> >> >> > 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 <[hidden email]>
>> >> >> >> wrote:
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On Fri, Jan 29, 2016 at 10:26 AM, Pierre-Anthony Lemieux
>> >> >> >> > <[hidden email]>
>> >> >> >> > 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
>> >> >> >> >> <[hidden email]>
>> >> >> >> >> wrote:
>> >> >> >> >> > I can provide some respond to this.
>> >> >> >> >> >
>> >> >> >> >> > On Fri, Jan 29, 2016 at 8:14 AM, Pierre-Anthony Lemieux
>> >> >> >> >> > <[hidden email]>
>> >> >> >> >> > 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

  ­­  

 

----------------------------

http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------


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
  ­­  
Reply | Threaded
Open this post in threaded view
|

Re: <initial> vs inherited

Glenn Adams-2
In reply to this post by John Birch-3


On Wed, Feb 3, 2016 at 3:12 AM, John Birch <[hidden email]> 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

 

 

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 : <a href="tel:%2B44%201473%20831700" value="+441473831700" target="_blank">+44 1473 831700 | Ext : 2208 | Direct Dial : <a href="tel:%2B44%201473%20834532" value="+441473834532" target="_blank">+44 1473 834532
Mobile : <a href="tel:%2B44%207919%20558380" value="+447919558380" target="_blank">+44 7919 558380 | Fax : <a href="tel:%2B44%201473%20830078" value="+441473830078" target="_blank">+44 1473 830078
[hidden email] | 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:[hidden email]]
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 <[hidden email]> 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

 

 


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 <[hidden email]> wrote:
>
>
> On Tue, Feb 2, 2016 at 6:13 PM, Pierre-Anthony Lemieux <[hidden email]>
> 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 <[hidden email]> wrote:
>> >
>> >
>> > On Tue, Feb 2, 2016 at 1:27 PM, Pierre-Anthony Lemieux
>> > <[hidden email]>
>> > 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 <[hidden email]> 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
>> >> > <[hidden email]>
>> >> > 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 <[hidden email]>
>> >> >> wrote:
>> >> >> >
>> >> >> >
>> >> >> > On Tue, Feb 2, 2016 at 12:28 PM, Pierre-Anthony Lemieux
>> >> >> > <[hidden email]>
>> >> >> > 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 <[hidden email]>
>> >> >> >> wrote:
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On Fri, Jan 29, 2016 at 10:26 AM, Pierre-Anthony Lemieux
>> >> >> >> > <[hidden email]>
>> >> >> >> > 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
>> >> >> >> >> <[hidden email]>
>> >> >> >> >> wrote:
>> >> >> >> >> > I can provide some respond to this.
>> >> >> >> >> >
>> >> >> >> >> > On Fri, Jan 29, 2016 at 8:14 AM, Pierre-Anthony Lemieux
>> >> >> >> >> > <[hidden email]>
>> >> >> >> >> > 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
  ­­  

Reply | Threaded
Open this post in threaded view
|

Re: <initial> vs inherited

Dae Kim
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 <[hidden email]> wrote:


On Wed, Feb 3, 2016 at 3:12 AM, John Birch <[hidden email]> 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

 

 

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 : <a href="tel:%2B44%201473%20831700" value="+441473831700" target="_blank">+44 1473 831700 | Ext : 2208 | Direct Dial : <a href="tel:%2B44%201473%20834532" value="+441473834532" target="_blank">+44 1473 834532
Mobile : <a href="tel:%2B44%207919%20558380" value="+447919558380" target="_blank">+44 7919 558380 | Fax : <a href="tel:%2B44%201473%20830078" value="+441473830078" target="_blank">+44 1473 830078
[hidden email] | 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:[hidden email]]
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 <[hidden email]> 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

 

 


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 <[hidden email]> wrote:
>
>
> On Tue, Feb 2, 2016 at 6:13 PM, Pierre-Anthony Lemieux <[hidden email]>
> 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 <[hidden email]> wrote:
>> >
>> >
>> > On Tue, Feb 2, 2016 at 1:27 PM, Pierre-Anthony Lemieux
>> > <[hidden email]>
>> > 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 <[hidden email]> 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
>> >> > <[hidden email]>
>> >> > 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 <[hidden email]>
>> >> >> wrote:
>> >> >> >
>> >> >> >
>> >> >> > On Tue, Feb 2, 2016 at 12:28 PM, Pierre-Anthony Lemieux
>> >> >> > <[hidden email]>
>> >> >> > 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 <[hidden email]>
>> >> >> >> wrote:
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On Fri, Jan 29, 2016 at 10:26 AM, Pierre-Anthony Lemieux
>> >> >> >> > <[hidden email]>
>> >> >> >> > 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
>> >> >> >> >> <[hidden email]>
>> >> >> >> >> wrote:
>> >> >> >> >> > I can provide some respond to this.
>> >> >> >> >> >
>> >> >> >> >> > On Fri, Jan 29, 2016 at 8:14 AM, Pierre-Anthony Lemieux
>> >> >> >> >> > <[hidden email]>
>> >> >> >> >> > 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
  ­­  


Reply | Threaded
Open this post in threaded view
|

Re: <initial> vs inherited

Pierre-Anthony Lemieux
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?

Happy to discuss on the call next week.

Best,

-- Pierre

On Thu, Mar 31, 2016 at 11:06 AM, Dae Kim <[hidden email]> 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 <[hidden email]> wrote:
>>
>>
>>
>> On Wed, Feb 3, 2016 at 3:12 AM, John Birch <[hidden email]>
>> 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
>>> [hidden email] | 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:[hidden email]]
>>> 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
>>> <[hidden email]> 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 <[hidden email]> wrote:
>>> >
>>> >
>>> > On Tue, Feb 2, 2016 at 6:13 PM, Pierre-Anthony Lemieux
>>> > <[hidden email]>
>>> > 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 <[hidden email]> wrote:
>>> >> >
>>> >> >
>>> >> > On Tue, Feb 2, 2016 at 1:27 PM, Pierre-Anthony Lemieux
>>> >> > <[hidden email]>
>>> >> > 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 <[hidden email]>
>>> >> >> 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
>>> >> >> > <[hidden email]>
>>> >> >> > 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 <[hidden email]>
>>> >> >> >> wrote:
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> > On Tue, Feb 2, 2016 at 12:28 PM, Pierre-Anthony Lemieux
>>> >> >> >> > <[hidden email]>
>>> >> >> >> > 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
>>> >> >> >> >> <[hidden email]>
>>> >> >> >> >> wrote:
>>> >> >> >> >> >
>>> >> >> >> >> >
>>> >> >> >> >> > On Fri, Jan 29, 2016 at 10:26 AM, Pierre-Anthony Lemieux
>>> >> >> >> >> > <[hidden email]>
>>> >> >> >> >> > 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
>>> >> >> >> >> >> <[hidden email]>
>>> >> >> >> >> >> wrote:
>>> >> >> >> >> >> > I can provide some respond to this.
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > On Fri, Jan 29, 2016 at 8:14 AM, Pierre-Anthony Lemieux
>>> >> >> >> >> >> > <[hidden email]>
>>> >> >> >> >> >> > 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
>>>   ­­
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: <initial> vs inherited

Glenn Adams-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>
>>
>>
>> On Wed, Feb 3, 2016 at 3:12 AM, John Birch <[hidden email]>
>> 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 : <a href="tel:%2B44%201473%20831700" value="+441473831700">+44 1473 831700 | Ext : 2208 | Direct Dial : <a href="tel:%2B44%201473%20834532" value="+441473834532">+44 1473 834532
>>> Mobile : <a href="tel:%2B44%207919%20558380" value="+447919558380">+44 7919 558380 | Fax : <a href="tel:%2B44%201473%20830078" value="+441473830078">+44 1473 830078
>>> [hidden email] | 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:[hidden email]]
>>> 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
>>> <[hidden email]> 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 <[hidden email]> wrote:
>>> >
>>> >
>>> > On Tue, Feb 2, 2016 at 6:13 PM, Pierre-Anthony Lemieux
>>> > <[hidden email]>
>>> > 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 <[hidden email]> wrote:
>>> >> >
>>> >> >
>>> >> > On Tue, Feb 2, 2016 at 1:27 PM, Pierre-Anthony Lemieux
>>> >> > <[hidden email]>
>>> >> > 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 <[hidden email]>
>>> >> >> 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
>>> >> >> > <[hidden email]>
>>> >> >> > 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 <[hidden email]>
>>> >> >> >> wrote:
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> > On Tue, Feb 2, 2016 at 12:28 PM, Pierre-Anthony Lemieux
>>> >> >> >> > <[hidden email]>
>>> >> >> >> > 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
>>> >> >> >> >> <[hidden email]>
>>> >> >> >> >> wrote:
>>> >> >> >> >> >
>>> >> >> >> >> >
>>> >> >> >> >> > On Fri, Jan 29, 2016 at 10:26 AM, Pierre-Anthony Lemieux
>>> >> >> >> >> > <[hidden email]>
>>> >> >> >> >> > 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
>>> >> >> >> >> >> <[hidden email]>
>>> >> >> >> >> >> wrote:
>>> >> >> >> >> >> > I can provide some respond to this.
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > On Fri, Jan 29, 2016 at 8:14 AM, Pierre-Anthony Lemieux
>>> >> >> >> >> >> > <[hidden email]>
>>> >> >> >> >> >> > 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
>>>   ­­
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: <initial> vs inherited

nigelmegitt
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: <a dir="ltr" href="tel:&#43;44%C2%A03030807996" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="2/1">+44 <a dir="ltr" href="tel:&#43;44%C2%A03030807996" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="2/1">(0)3030807996 

BC2 C1 Broadcast Centre, Media Village, <a dir="ltr" href="x-apple-data-detectors://3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="3">201 Wood Lane, London W12 7TP


On 31 Mar 2016, at 20:49, Glenn Adams <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>
>>
>>
>> On Wed, Feb 3, 2016 at 3:12 AM, John Birch <[hidden email]>
>> 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 : <a href="tel:%2B44%201473%20831700" value="&#43;441473831700">+44 1473 831700 | Ext : 2208 | Direct Dial : <a href="tel:%2B44%201473%20834532" value="&#43;441473834532">+44 1473 834532
>>> Mobile : <a href="tel:%2B44%207919%20558380" value="&#43;447919558380">+44 7919 558380 | Fax : <a href="tel:%2B44%201473%20830078" value="&#43;441473830078">+44 1473 830078
>>> [hidden email] | 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:[hidden email]]
>>> 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
>>> <[hidden email]> 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 <[hidden email]> wrote:
>>> >
>>> >
>>> > On Tue, Feb 2, 2016 at 6:13 PM, Pierre-Anthony Lemieux
>>> > <[hidden email]>
>>> > 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 <[hidden email]> wrote:
>>> >> >
>>> >> >
>>> >> > On Tue, Feb 2, 2016 at 1:27 PM, Pierre-Anthony Lemieux
>>> >> > <[hidden email]>
>>> >> > 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 <[hidden email]>
>>> >> >> 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
>>> >> >> > <[hidden email]>
>>> >> >> > 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 <[hidden email]>
>>> >> >> >> wrote:
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> > On Tue, Feb 2, 2016 at 12:28 PM, Pierre-Anthony Lemieux
>>> >> >> >> > <[hidden email]>
>>> >> >> >> > 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
>>> >> >> >> >> <[hidden email]>
>>> >> >> >> >> wrote:
>>> >> >> >> >> >
>>> >> >> >> >> >
>>> >> >> >> >> > On Fri, Jan 29, 2016 at 10:26 AM, Pierre-Anthony Lemieux
>>> >> >> >> >> > <[hidden email]>
>>> >> >> >> >> > 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
>>> >> >> >> >> >> <[hidden email]>
>>> >> >> >> >> >> wrote:
>>> >> >> >> >> >> > I can provide some respond to this.
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > On Fri, Jan 29, 2016 at 8:14 AM, Pierre-Anthony Lemieux
>>> >> >> >> >> >> > <[hidden email]>
>>> >> >> >> >> >> > 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
>>>   ­­
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: <initial> vs inherited

Glenn Adams-2
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 <[hidden email]> 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: <a dir="ltr" href="tel:+44%C2%A03030807996" target="_blank">+44 <a dir="ltr" href="tel:+44%C2%A03030807996" target="_blank">(0)3030807996 

BC2 C1 Broadcast Centre, Media Village, 201 Wood Lane, London W12 7TP


On 31 Mar 2016, at 20:49, Glenn Adams <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>
>>
>>
>> On Wed, Feb 3, 2016 at 3:12 AM, John Birch <[hidden email]>
>> 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 : <a href="tel:%2B44%201473%20831700" value="+441473831700" target="_blank">+44 1473 831700 | Ext : 2208 | Direct Dial : <a href="tel:%2B44%201473%20834532" value="+441473834532" target="_blank">+44 1473 834532
>>> Mobile : <a href="tel:%2B44%207919%20558380" value="+447919558380" target="_blank">+44 7919 558380 | Fax : <a href="tel:%2B44%201473%20830078" value="+441473830078" target="_blank">+44 1473 830078
>>> [hidden email] | 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:[hidden email]]
>>> 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
>>> <[hidden email]> 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 <[hidden email]> wrote:
>>> >
>>> >
>>> > On Tue, Feb 2, 2016 at 6:13 PM, Pierre-Anthony Lemieux
>>> > <[hidden email]>
>>> > 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 <[hidden email]> wrote:
>>> >> >
>>> >> >
>>> >> > On Tue, Feb 2, 2016 at 1:27 PM, Pierre-Anthony Lemieux
>>> >> > <[hidden email]>
>>> >> > 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 <[hidden email]>
>>> >> >> 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
>>> >> >> > <[hidden email]>
>>> >> >> > 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 <[hidden email]>
>>> >> >> >> wrote:
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> > On Tue, Feb 2, 2016 at 12:28 PM, Pierre-Anthony Lemieux
>>> >> >> >> > <[hidden email]>
>>> >> >> >> > 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
>>> >> >> >> >> <[hidden email]>
>>> >> >> >> >> wrote:
>>> >> >> >> >> >
>>> >> >> >> >> >
>>> >> >> >> >> > On Fri, Jan 29, 2016 at 10:26 AM, Pierre-Anthony Lemieux
>>> >> >> >> >> > <[hidden email]>
>>> >> >> >> >> > 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
>>> >> >> >> >> >> <[hidden email]>
>>> >> >> >> >> >> wrote:
>>> >> >> >> >> >> > I can provide some respond to this.
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > On Fri, Jan 29, 2016 at 8:14 AM, Pierre-Anthony Lemieux
>>> >> >> >> >> >> > <[hidden email]>
>>> >> >> >> >> >> > 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
>>>   ­­
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: <initial> vs inherited

nigelmegitt
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
* 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 <[hidden email]>
Date: Tuesday, 5 April 2016 18:50
To: Nigel Megitt <[hidden email]>
Cc: TTWG <[hidden email]>, Pierre-Anthony Lemieux <[hidden email]>, Dae Kim <[hidden email]>, John Birch <[hidden email]>
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 <[hidden email]> 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: <a dir="ltr" href="tel:&#43;44%C2%A03030807996" target="_blank">+44 <a dir="ltr" href="tel:&#43;44%C2%A03030807996" target="_blank">(0)3030807996 

BC2 C1 Broadcast Centre, Media Village, 201 Wood Lane, London W12 7TP


On 31 Mar 2016, at 20:49, Glenn Adams <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>
>>
>>
>> On Wed, Feb 3, 2016 at 3:12 AM, John Birch <[hidden email]>
>> 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 : <a href="tel:%2B44%201473%20831700" value="&#43;441473831700" target="_blank"> +44 1473 831700 | Ext : 2208 | Direct Dial : <a href="tel:%2B44%201473%20834532" value="&#43;441473834532" target="_blank"> +44 1473 834532
>>> Mobile : <a href="tel:%2B44%207919%20558380" value="&#43;447919558380" target="_blank"> +44 7919 558380 | Fax : <a href="tel:%2B44%201473%20830078" value="&#43;441473830078" target="_blank"> +44 1473 830078
>>> [hidden email] | 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:[hidden email]]
>>> 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
>>> <[hidden email]> 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 <[hidden email]> wrote:
>>> >
>>> >
>>> > On Tue, Feb 2, 2016 at 6:13 PM, Pierre-Anthony Lemieux
>>> > <[hidden email]>
>>> > 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 <[hidden email]> wrote:
>>> >> >
>>> >> >
>>> >> > On Tue, Feb 2, 2016 at 1:27 PM, Pierre-Anthony Lemieux
>>> >> > <[hidden email]>
>>> >> > 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 <[hidden email]>
>>> >> >> 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
>>> >> >> > <[hidden email]>
>>> >> >> > 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 <[hidden email]>
>>> >> >> >> wrote:
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> > On Tue, Feb 2, 2016 at 12:28 PM, Pierre-Anthony Lemieux
>>> >> >> >> > <[hidden email]>
>>> >> >> >> > 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
>>> >> >> >> >> <[hidden email]>
>>> >> >> >> >> wrote:
>>> >> >> >> >> >
>>> >> >> >> >> >
>>> >> >> >> >> > On Fri, Jan 29, 2016 at 10:26 AM, Pierre-Anthony Lemieux
>>> >> >> >> >> > <[hidden email]>
>>> >> >> >> >> > 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
>>> >> >> >> >> >> <[hidden email]>
>>> >> >> >> >> >> wrote:
>>> >> >> >> >> >> > I can provide some respond to this.
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > On Fri, Jan 29, 2016 at 8:14 AM, Pierre-Anthony Lemieux
>>> >> >> >> >> >> > <[hidden email]>
>>> >> >> >> >> >> > 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
>>>   ­­
>>
>>
>


12