FW: TTML2 horizontal review with CSS

Cross posting this (public) message to CSS WG to the TTWG reflector to
fulfil Action-490.

Thank you for the feedback David, the TTWG is interested in reading this
and would like CSS WG (or other Wgs) to consider adding any features that
have requirements in general for the web platform but that are not yet
fully supported; some parts of TTML2 include such features.

I for one have an outstanding action from TPAC to raise an issue
concerning the block progression size ("height") of content rectangles, to
deal with one requirement.



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

>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-vocabula

>>ry
>>
>> 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)



-----------------------------
http://www.bbc.co.uk

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
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

Received on Thursday, 8 December 2016 16:14:15 UTC