- From: Glenn Adams <glenn@skynav.com>
- Date: Tue, 2 Feb 2016 12:55:08 -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+diTVa6jZansu5_kSvftsFjx6jGzQQSBru4bWg7NLMk8g@mail.gmail.com>
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 19:55:56 UTC