Re: <initial> vs inherited

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