W3C home > Mailing lists > Public > public-tt@w3.org > February 2016

Re: <initial> vs inherited

From: Pierre-Anthony Lemieux <pal@sandflow.com>
Date: Tue, 2 Feb 2016 21:58:55 -0800
Message-ID: <CAF_7JxC5Grgg6cj6t-CrUnvYvD2jgRKeDV82JbUnKjwJr7chWg@mail.gmail.com>
To: Glenn Adams <glenn@skynav.com>
Cc: Dae Kim <dakim@netflix.com>, Nigel Megitt <nigel.megitt@bbc.co.uk>, TTWG <public-tt@w3.org>
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 <glenn@skynav.com> wrote:
>
>
> On Tue, Feb 2, 2016 at 6:13 PM, Pierre-Anthony Lemieux <pal@sandflow.com>
> wrote:
>>
>> Hi Glenn,
>>
>> Ok. What is the downside of using style inheritance to avoid having to
>> set a property explicitly throughout the document, i.e. have all
>> styles derive from a top-level style that overrides the initial
>> values?
>
>
> firstly, this question is well formed only with respect to inheritable
> properties; it doesn't apply to non-inheritable properties;
>
> so, for an inheritable property, in TTML1, the only option is to specify the
> property on the top-most inheritable element, namely, on region; so, e.g.,
>
> <region tts:color='yellow'/>
>
> however, if there are multiple regions, one would be forced to specify this
> on each region in turn; alternatively, one might specify:
>
> <body tts:color='yellow'>...</body>
>
> which effectively applies to all content that may be rendered in any region;
> however, this would not be a viable strategy for an inheritable property
> that to both region and body, such as tts:visible: it is only viable for an
> inheritable property that applies to body or a descendant of body and does
> not apply to region, e.g., tts:color;
>
> in contrast, in TTML2, again for inheritable properties only, we have the
> option of either specifying the property on (1) the top-most inheritable
> element, namely, on tt, or on (2) an initial element, which has the effect
> of overriding the initial value applied to the top-most inheritable element;
>
>
>>
>>
>> Best,
>>
>> -- Pierre
>>
>> On Tue, Feb 2, 2016 at 1:08 PM, Glenn Adams <glenn@skynav.com> wrote:
>> >
>> >
>> > On Tue, Feb 2, 2016 at 1:27 PM, Pierre-Anthony Lemieux
>> > <pal@sandflow.com>
>> > wrote:
>> >>
>> >> Hi Glenn,
>> >>
>> >> Ok. What approach does XSL-FO and/or CSS take to allowing authors to
>> >> avoid having to explicitly set a property through the document?
>> >
>> >
>> > For non-inheritable properties, there is no mechanism other than direct
>> > specification (XSL-FO) or a style rule or style attribute (CSS). Also,
>> > initial values (for inheritable and non-inheritable properties) cannot
>> > be
>> > overridden in either XSL-FO or CSS, so defining an initial element for
>> > this
>> > purpose in TTML2 is effectively a new mechanism not found in either
>> > XSL-FO
>> > or CSS.
>> >
>> >>
>> >>
>> >> Thanks,
>> >>
>> >> -- Pierre
>> >>
>> >> On Tue, Feb 2, 2016 at 11:55 AM, Glenn Adams <glenn@skynav.com> wrote:
>> >> > Because that is not how the semantics of styles in XSL-FO or CSS
>> >> > work,
>> >> > and
>> >> > thus not how the semantics work in TTML (of any flavor).
>> >> >
>> >> > Specifying a non-inheritable property on an element to which that
>> >> > property
>> >> > does not apply is a NO-OP.
>> >> >
>> >> > In TTML1 we have the following (Section 8.2):
>> >> >
>> >> > Note:
>> >> >
>> >> > Due to the general syntax of this specification (and the schemas it
>> >> > references) with respect to how style attributes are specified,
>> >> > particularly
>> >> > for the purpose of supporting inheritance, it is possible for an
>> >> > author
>> >> > to
>> >> > inadvertently specify a non-inheritable style attribute on an element
>> >> > that
>> >> > applies neither to that element or any of its descendants while still
>> >> > remaining conformant from a content validity perspective. Content
>> >> > authors
>> >> > may wish to make use of TTML content verification tools that detect
>> >> > and
>> >> > warn
>> >> > about such usage.
>> >> >
>> >> > In TTML2 we promoted this to normative language (Section 10.2):
>> >> >
>> >> > Unless explicitly permitted by an element type definition, an
>> >> > attribute
>> >> > in
>> >> > the TT Style Namespace should not be specified on an element unless
>> >> > it
>> >> > either applies to that element or denotes an inheritable style
>> >> > property.
>> >> > If
>> >> > it does not apply to that element and does not denote an inheritable
>> >> > style
>> >> > property, then it must be ignored for the purpose of non-validation
>> >> > processing. In the case of validation processing, such usage should
>> >> > be
>> >> > reported as a warning, or, if strict validation is performed, as an
>> >> > error.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On Tue, Feb 2, 2016 at 12:48 PM, Pierre-Anthony Lemieux
>> >> > <pal@sandflow.com>
>> >> > wrote:
>> >> >>
>> >> >> Hi Glenn,
>> >> >>
>> >> >> > tts:backgroundColor
>> >> >>
>> >> >> Can you remind us why specifying tts:backgroundColor="X" on <tt>
>> >> >> could
>> >> >> not mean "set initial value of tts:backgroundColor to X"?
>> >> >>
>> >> >> Best,
>> >> >>
>> >> >> -- Pierre
>> >> >>
>> >> >> On Tue, Feb 2, 2016 at 11:42 AM, Glenn Adams <glenn@skynav.com>
>> >> >> wrote:
>> >> >> >
>> >> >> >
>> >> >> > On Tue, Feb 2, 2016 at 12:28 PM, Pierre-Anthony Lemieux
>> >> >> > <pal@sandflow.com>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> Hi Glenn et al.,
>> >> >> >>
>> >> >> >> >Perhaps we need to review
>> >> >> >> > uninheritable properties in TTML2 to determine if we need to
>> >> >> >> > upgrade
>> >> >> >> > them to
>> >> >> >> > inheritable,
>> >> >> >>
>> >> >> >> I like the idea of having a single mechanism for setting an
>> >> >> >> initial
>> >> >> >> value for properties, i.e. avoid having to set a property
>> >> >> >> explicitly
>> >> >> >> throughout the document.
>> >> >> >>
>> >> >> >> Expanding inheritance (instead of introducing a new <initial>
>> >> >> >> element)
>> >> >> >> seems promising, and intuitive.
>> >> >> >
>> >> >> >
>> >> >> > That won't be sufficient, since we will not be able to make
>> >> >> > everything
>> >> >> > inherit. The reason for this is related to the semantics of
>> >> >> > specific
>> >> >> > style
>> >> >> > properties. For example, the following cannot inherit:
>> >> >> >
>> >> >> > tts:backgroundColor
>> >> >> > tts:backgroundImage
>> >> >> > tts:backgroundPosition
>> >> >> > tts:backgroundRepeat
>> >> >> > tts:border
>> >> >> > tts:bpd
>> >> >> > tts:display
>> >> >> > tts:extent
>> >> >> > tts:ipd
>> >> >> > tts:opacity
>> >> >> > tts:origin
>> >> >> > tts:overflow
>> >> >> > tts:padding
>> >> >> > tts:position
>> >> >> > tts:ruby
>> >> >> > tts:unicodeBidi
>> >> >> > tts:writingMode
>> >> >> > tts:zIndex
>> >> >> >
>> >> >> > Possible candidates for upgrading to inheritable are:
>> >> >> >
>> >> >> > tts:displayAlign
>> >> >> > tts:showBackground
>> >> >> >
>> >> >> > So really, only these two are potentially able to be recast as
>> >> >> > inheritable
>> >> >> > in TTML2. All the rest (above) rely on initial value, and, for
>> >> >> > that
>> >> >> > matter,
>> >> >> > initial value also applies to inheritable properties at the top of
>> >> >> > the
>> >> >> > inheritance tree (region in TTML1, tt in TTML2).
>> >> >> >
>> >> >> > The initial element is already written into the TTML2 spec,
>> >> >> > implemented,
>> >> >> > deployed, and previously discussed in the WG (though perhaps we
>> >> >> > didn't
>> >> >> > dive
>> >> >> > in too deeply).
>> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >> > though doing so will require careful consideration of
>> >> >> >> > interoperability with TTML1 behavior.
>> >> >> >>
>> >> >> >> I see two scenarios:
>> >> >> >>
>> >> >> >> - an author wishes to create a document that conforms to both
>> >> >> >> TTML1
>> >> >> >> and TTML2, in which case the author should set the property
>> >> >> >> explicitly
>> >> >> >> throughout the document -- this is always safe.
>> >> >> >>
>> >> >> >> - an author wishes to target only TTML2 processors, in which the
>> >> >> >> author can rely on the expanded inheritance rules
>> >> >> >>
>> >> >> >> Are there other scenarios?
>> >> >> >>
>> >> >> >> Best,
>> >> >> >>
>> >> >> >> -- Pierre
>> >> >> >>
>> >> >> >> On Fri, Jan 29, 2016 at 9:33 AM, Glenn Adams <glenn@skynav.com>
>> >> >> >> wrote:
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On Fri, Jan 29, 2016 at 10:26 AM, Pierre-Anthony Lemieux
>> >> >> >> > <pal@sandflow.com>
>> >> >> >> > wrote:
>> >> >> >> >>
>> >> >> >> >> Hi Glenn,
>> >> >> >> >>
>> >> >> >> >> > This could also be done in other ways, such as by specifying
>> >> >> >> >> > these
>> >> >> >> >> > properties on the tt element,
>> >> >> >> >> > from which all inheritance would occur (in TTML2); however,
>> >> >> >> >> > that
>> >> >> >> >> > wouldn't work for properties
>> >> >> >> >> > that don't inherit, like tts:showBackground, etc.
>> >> >> >> >>
>> >> >> >> >> Why doesn't tts:showBackground inherit?
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > It was originally defined on region in TTML1, which has no way
>> >> >> >> > for
>> >> >> >> > a
>> >> >> >> > region
>> >> >> >> > to inherit. However, we are adding root element inheritance in
>> >> >> >> > TTML2
>> >> >> >> > (e.g.,
>> >> >> >> > from tt to head to layout to region). Perhaps we need to review
>> >> >> >> > uninheritable properties in TTML2 to determine if we need to
>> >> >> >> > upgrade
>> >> >> >> > them to
>> >> >> >> > inheritable, though doing so will require careful consideration
>> >> >> >> > of
>> >> >> >> > interoperability with TTML1 behavior.
>> >> >> >> >
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> Thanks,
>> >> >> >> >>
>> >> >> >> >> -- Pierre
>> >> >> >> >>
>> >> >> >> >> On Fri, Jan 29, 2016 at 9:11 AM, Glenn Adams
>> >> >> >> >> <glenn@skynav.com>
>> >> >> >> >> wrote:
>> >> >> >> >> > I can provide some respond to this.
>> >> >> >> >> >
>> >> >> >> >> > On Fri, Jan 29, 2016 at 8:14 AM, Pierre-Anthony Lemieux
>> >> >> >> >> > <pal@sandflow.com>
>> >> >> >> >> > wrote:
>> >> >> >> >> >>
>> >> >> >> >> >> Hi Dae,
>> >> >> >> >> >>
>> >> >> >> >> >> > initial
>> >> >> >> >> >>
>> >> >> >> >> >> How does Netflix plan to use <initial>?
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> > The TTT tools already support the initial element with the
>> >> >> >> >> > ttml2
>> >> >> >> >> > model,
>> >> >> >> >> > and
>> >> >> >> >> > has found it to be very useful in specifying a variety of
>> >> >> >> >> > non-default,
>> >> >> >> >> > global style settings, such as default color and font
>> >> >> >> >> > related
>> >> >> >> >> > properties,
>> >> >> >> >> > etc.
>> >> >> >> >> >
>> >> >> >> >> > For example, the CAP2TT tool in TTT specifies a test
>> >> >> >> >> > configuration
>> >> >> >> >> > file
>> >> >> >> >> > that
>> >> >> >> >> > specifies a template for generating TTML2 output files in
>> >> >> >> >> > which
>> >> >> >> >> > is
>> >> >> >> >> > specified
>> >> >> >> >> > the following:
>> >> >> >> >> >
>> >> >> >> >> > <initial tts:fontSize="4vh"/>
>> >> >> >> >> > <initial tts:lineHeight="5vh"/>
>> >> >> >> >> > <initial tts:showBackground="whenActive"/>
>> >> >> >> >> >
>> >> >> >> >> > Here, initial is used to alter the default initial value.
>> >> >> >> >> > This
>> >> >> >> >> > could
>> >> >> >> >> > also be
>> >> >> >> >> > done in other ways, such as by specifying these properties
>> >> >> >> >> > on
>> >> >> >> >> > the
>> >> >> >> >> > tt
>> >> >> >> >> > element, from which all inheritance would occur (in TTML2);
>> >> >> >> >> > however,
>> >> >> >> >> > that
>> >> >> >> >> > wouldn't work for properties that don't inherit, like
>> >> >> >> >> > tts:showBackground,
>> >> >> >> >> > etc.
>> >> >> >> >> >
>> >> >> >> >> > Note that be using initial to specify an explicit
>> >> >> >> >> > tts:lineHeight,
>> >> >> >> >> > then
>> >> >> >> >> > there
>> >> >> >> >> > is no possibility of using the default initial value of
>> >> >> >> >> > 'normal'
>> >> >> >> >> > (which
>> >> >> >> >> > has
>> >> >> >> >> > been a problem with IMSC content).
>> >> >> >> >> >
>> >> >> >> >> > It is also useful for redefining the default initial value
>> >> >> >> >> > of
>> >> >> >> >> > tts:backgroundColor and resolving the platform dependent
>> >> >> >> >> > default
>> >> >> >> >> > initial
>> >> >> >> >> > value of tts:color.
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >
>> >
>
>
Received on Wednesday, 3 February 2016 05:59:46 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:27 UTC