Re: <initial> vs inherited from Glenn Adams on 2016-02-03 (public-tt@w3.org from February 2016)

From: Glenn Adams <glenn@skynav.com>
Date: Tue, 2 Feb 2016 21:26:46 -0700
To: Pierre-Anthony Lemieux <pal@sandflow.com>
Cc: Dae Kim <dakim@netflix.com>, Nigel Megitt <nigel.megitt@bbc.co.uk>, TTWG <public-tt@w3.org>
Message-ID: <CACQ=j+dOxVciWm9Dx2sY6CSzgtCR5=S2trZhgbmSgEk3reEwMQ@mail.gmail.com>
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 04:27:34 UTC