Re: TTML2 horizontal review with CSS

On Friday 2016-11-18 17:48 +0100, Thierry MICHEL wrote:
> CSS colleagues,
> 
> The Timed Text Working Group (TTWG) published yesterday an ordinary Working
> Draft of Timed Text Markup Language 2 (TTML2)
> W3C Working Draft 17 November 2016
> https://www.w3.org/TR/2016/WD-ttml2-20161117/
> 
> 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 Language
> (TTML) Version 1 (TTML1) and Version 2 (TTML2).
> https://www.w3.org/TR/2016/WD-ttml2-20161117/#changes-from-ttml1-vocabulary
> 
> Please send your comments to  TTWG Public mailing list <public-tt@w3.org>.

So it's worth noting that the styling section of the draft:
  https://w3c.github.io/ttml2/spec/ttml2.html#styling
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
https://www.w3.org/TR/ttaf1-dfxp/#styling-attribute-vocabulary
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
divergence.

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             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)