Re: <initial> vs inherited

Hi Dae,

Apologies for not following-up on that thread. My mind has been
focused on IMSC1 lately. I have the following question based on the
thread.

> regions in TTML{1,2} can freely make use of the @style attribute to referenced defined styles including chained styles

Ok, so what does this not achieve that <initial> achieve in practice?

Happy to discuss on the call next week.

Best,

-- Pierre

On Thu, Mar 31, 2016 at 11:06 AM, Dae Kim <dakim@netflix.com> wrote:
> I've not seen any movement on this topic in the issues or in the meeting
> notes.
> Are we happy/content with <initial> or should we add this to next week's
> agenda?
>
> -Dae
>
> Dae Kim | Video Engineer | Encoding Technology
> 9420 94f4 a834 b038 2920 34b3 38ad b632 3738 942c 942f
>
> On Wed, Feb 3, 2016 at 7:55 AM, Glenn Adams <glenn@skynav.com> wrote:
>>
>>
>>
>> On Wed, Feb 3, 2016 at 3:12 AM, John Birch <John.Birch@screensystems.tv>
>> wrote:
>>>
>>> This is probably a silly question…. But would it be feasible to have an
>>> optional ‘container’ element in TTML2 for multiple region definitions within
>>> which you can set style(s) that would then be inherited /inheritable by any
>>> child region elements?
>>
>>
>> the layout element could potentially be used, but we decided a while back
>> to use root (tt) instead to manage inheritance by region; see [1]; of course
>> this is a TTML2 only feature
>>
>> [1]
>> https://rawgit.com/w3c/ttml2/master/spec/ttml2.html#semantics-style-inheritance-root
>>
>>>
>>>
>>>
>>> e.g.
>>>
>>>
>>>
>>> <style xml:id="initialStyle" tts:color="white"
>>> tts:fontFamily="monospaceSerif" tts:textAlign="start" etc…/>
>>>
>>>
>>>
>>> <regions style =”initialStyle”>
>>>
>>> <region xml:id="r1">
>>>
>>>   <style tts:color="green"/>
>>>
>>>   <style tts:textAlign="center"/>
>>>
>>> </region>
>>>
>>> <region xml:id="r2">
>>>
>>>   <style tts:color="yellow"/>
>>>
>>>   <style tts:textAlign="center"/>
>>>
>>> </region>
>>>
>>> </regions>
>>>
>>>
>>>
>>> Of course such a TTML2 document could not be processed correctly by a
>>> TTML1 processor, but could be down converted by repeating the initial style
>>> values into each region definition.
>>>
>>>
>>>
>>> Alternatively, what about allowing chained referential regions… so the
>>> initial values are set in a region (probably one that is not referenced
>>> directly by content) that is then referenced by other region definitions.
>>
>>
>> regions in TTML{1,2} can freely make use of the @style attribute to
>> referenced defined styles including chained styles
>>
>>>
>>>
>>>
>>> Like I said, probably silly ideas but just wondering what’s possible.
>>>
>>>
>>>
>>> Best regards,
>>>
>>> John
>>>
>>>
>>>
>>> John Birch | Strategic Partnerships Manager | Screen
>>> Main Line : +44 1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532
>>> Mobile : +44 7919 558380 | Fax : +44 1473 830078
>>> John.Birch@screensystems.tv | www.screensystems.tv |
>>> https://twitter.com/screensystems
>>>
>>> Visit us at
>>> BVE, London Excel, 23-25 February 2016, stand C20
>>>
>>> P Before printing, think about the environment
>>>
>>>
>>> From: Glenn Adams [mailto:glenn@skynav.com]
>>> Sent: 03 February 2016 06:37
>>> To: Pierre-Anthony Lemieux
>>> Cc: Dae Kim; Nigel Megitt; TTWG
>>> Subject: Re: <initial> vs inherited
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Feb 2, 2016 at 10:58 PM, Pierre-Anthony Lemieux
>>> <pal@sandflow.com> wrote:
>>>
>>> Hi Glenn,
>>>
>>> > firstly, this question is well formed only with respect to inheritable
>>> > properties; it doesn't apply to non-inheritable properties;
>>>
>>> Oh. I was thinking of using chained referential styling, i.e. define a
>>> style element with desired 'initial' values
>>>
>>> <style xml:id="s1" tts:color="white" tts:fontFamily="monospaceSerif"/>
>>>
>>> and reference the style in all other styles, e.g.
>>>
>>> <style xml:id="s2" style="s1" tts:color="yellow"/>
>>>
>>> Why would that not work?
>>>
>>>
>>>
>>> sure, that is possible, but that isn't using inheritance or initial value
>>> overrides per se; use of @style is just a shorthand for direct (inline)
>>> specification of styles on a given element;
>>>
>>>
>>> TTML1 states: "The use of chained referential styling encourages the
>>> grouping of style specifications into general and specific sets, which
>>> further aids in style specification reuse."
>>>
>>> >  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;
>>>
>>> Ah. An inheritable property applies to descendants in the document
>>> structure, and would not apply to a region into which one of these
>>> descendants flows. Is that right?
>>>
>>>
>>>
>>> whether a style property applies to a given element is independent of
>>> whether it is inheritable or not; each property specifies which elements it
>>> applies to (semantically) and whether it is inheritable or not;
>>>
>>>
>>>
>>> tts:visible happens to be the only inheritable property that applies both
>>> to region and content elements
>>>
>>>
>>>
>>>
>>> > tts:backgroundColor
>>>
>>> Why is backgroundColor not inheritable, whereas color is, BTW?
>>>
>>>
>>>
>>> well, it is not inheritable in XSL-FO or CSS, so that is one explanation;
>>> see [1] for some specifics
>>>
>>>
>>>
>>> [1]
>>> https://www.w3.org/wiki/Inheritance_and_cascade#Why_inheritance_is_useful
>>>
>>>
>>>
>>>
>>> I am pretty sure it was discussed 10 years ago, but I was not present :)
>>>
>>>
>>>
>>> actually it wasn't; we simply adopted the XSL-FO semantics which adopted
>>> the CSS2 semantics
>>>
>>>
>>>
>>>
>>> Best,
>>>
>>> -- Pierre
>>>
>>>
>>> On Tue, Feb 2, 2016 at 8:26 PM, Glenn Adams <glenn@skynav.com> wrote:
>>> >
>>> >
>>> > 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.
>>> >> >> >> >> >> >
>>> >> >> >> >> >> >
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >>
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >
>>> >> >
>>> >
>>> >
>>>
>>>
>>>
>>>
>>> This message may contain confidential and/or privileged information. If
>>> you are not the intended recipient you must not use, copy, disclose or take
>>> any action based on this message or any information herein. If you have
>>> received this message in error, please advise the sender immediately by
>>> reply e-mail and delete this message. Thank you for your cooperation. Screen
>>> Subtitling Systems Ltd. Registered in England No. 2596832. Registered
>>> Office: The Old Rectory, Claydon Church Lane, Claydon, Ipswich, Suffolk, IP6
>>> 0EQ
>>>   ­­
>>
>>
>

Received on Thursday, 31 March 2016 18:09:44 UTC