Re: TTML2 horizontal review with CSS


Thanks, David, for the useful analysis of TTML2 and CSS. I was not aware 
of this.

Divergence from CSS should be minimized as we work on a new version of 
TTML. In particular, ease of rendering TTML2 in the web platform by 
converting it in JS to CSS styled HTML should be a key requirement. 
TTML2 needs to be easily implementable in both web and native applications.

Pierre should be able to provide insights into any challenges on 
implementing TTML in HTML/JS, since he's done it for IMSC1.



*Jim Helman * | MovieLabs | o: +1.650.646.2277 m: +1.650.576.1755 | 
* * | 475 Sansome St., Suite 740, San Francisco, CA 

On 23/11/2016, 23:33, "L. David Baron" < 
<>> wrote:

>On Friday 2016-11-18 17:48 +0100, Thierry MICHEL wrote:
>> CSS colleagues,
>> The Timed Text Working Group (TTWG) published yesterday an ordinary
>> Draft of Timed Text Markup Language 2 (TTML2)
>> W3C Working Draft 17 November 2016
>> FYI, this publication is not the last publication before requesting
>> transition to Candidate Recommendation. The TTWG plans to publish a
>>final WD
>> soon. We will let you know.
>> Meanwhile, the TTWG invites you to review this TTML2 WD.
>> The horizontal review should focus only on the new features
>> introduced in TTML2.
>> Please refer to the section for changes between Timed Text Markup
>> (TTML) Version 1 (TTML1) and Version 2 (TTML2).
>> Please send your comments to  TTWG Public mailing list
>So it's worth noting that the styling section of the draft:
>has considerable new additions relative to TTML1.  This section
>contains a vocabulary that is rather similar to many CSS properties,
>but also contains significant divergence.
>In particular, TTML1 had in
>the following styling attributes that appear to match CSS at first
>glance, at least in semantics:
>  backgroundColor
>  color
>  direction
>  display (only auto vs. none)
>  extent (a shorthand for width and height)
>  fontFamily
>  fontSize
>  fontStyle
>  fontWeight
>  lineHeight
>  opacity
>  overflow
>  padding
>  textAlign
>  textDecoration (but with extra values)
>  unicodeBidi
>  visibility
>  wrapOption (like text-wrap in css-text-4)
>  writingMode (but using old values)
>  zIndex
>and the following styling attributes that do not match CSS:
>  displayAlign
>  origin (a bit like x and y in SVG)
>  showBackground
>  textOutline
>TTML2 introduces the following new properties that appear to have
>similar CSS properties at first glance:
>  backgroundClip (with different names for the values)
>  backgroundExtent (equivalent to background-size)
>  backgroundImage
>  backgroundOrigin (with different names for the values)
>  backgroundPosition
>  backgroundRepeat
>  border (with border-radius included in the property)
>  bpd (equivalent to block-size in css-logical-properties)
>  fontKerning (though without CSS's initial value, which is auto!)
>  ipd (equivalent to inline-size in css-logical-properties)
>  letterSpacing
>  ruby (this is done using the display property in CSS)
>  rubyAlign (with additional auto, end, and withBase values)
>  rubyPosition (with before/after names instead of over/under)
>  textCombine (equivalent to CSS text-combine-horizontal)
>  textEmphasis
>  textOrientation (but retaining the sidewaysLeft and sidewaysRight
>    values that CSS removed)
>  textShadow
>and the following that appear not to have corresponding CSS properties:
>  disparity
>  fontSelectionStrategy
>  fontShear
>  fontVariant (this is a property name used in CSS, but with a
>    different meaning!)
>  position (this is a property name used in CSS, but with a
>    different value, "center", although one that has been proposed
>    to be added to the CSS property)
>  rubyOffset
>  rubyOverflow
>  rubyOverhang
>  rubyOverhangClass
>  rubyReserve
>My opinion on this is that this seems like a lot of divergence from
>CSS.  It's divergence in naming (using different names for the same
>thing and the same names for different things), divergence in value
>spaces, and given that everything is redefined in the TTML spec
>(although often non-normatively "based on" CSS specs), almost
>certainly massive divergence in semantics.
>I think TTML and CSS have largely been implemented in separate
>implementations (which means that TTML has largely not been
>implemented in browsers), and I don't think TTML1 was designed in a
>way that would fit well in browser implementations.  That's why
>browsers implemented WebVTT instead.  I think continuing to diverge
>from CSS to this degree simply makes TTML implementation in browsers
>even less likely than it already was (which was already unlikely).
>On the flip side, I don't think fixing that divergence is
>particularly valuable (at least to browsers) since the communities
>are already separate, and I think the chance of getting substantial
>TTML implementation in browsers is low even without additional
>𝄞   L. David Baron    𝄂
>𝄢   Mozilla    𝄂
>             Before I built a wall I'd ask to know
>             What I was walling in or walling out,
>             And to whom I was like to give offense.
>               - Robert Frost, Mending Wall (1914)

This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to


*Jim Helman * | MovieLabs | o: +1.650.646.2277 m: +1.650.576.1755 | 
* * | 475 Sansome St., Suite 740, San Francisco, CA 

Received on Thursday, 8 December 2016 07:19:19 UTC