Re: <initial> vs inherited

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 <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 01:14:07 UTC