Re: <initial> vs inherited

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 <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 Tuesday, 2 February 2016 20:28:05 UTC