- From: Pierre-Anthony Lemieux <pal@sandflow.com>
- Date: Sun, 11 Dec 2016 21:04:58 -0800
- To: "L. David Baron" <dbaron@dbaron.org>
- Cc: Thierry MICHEL <tmichel@w3.org>, Bert Bos <bert@w3.org>, Chris Lilley <chris@w3.org>, www-style list <www-style@w3.org>, Nigel Megitt <nigel.megitt@bbc.co.uk>
Hi David et al., > I don't think TTML1 was designed in a > way that would fit well in browser implementations. I have been working on an open source JavaScript library [1] for rendering TTML1 documents to HTML5 fragments. [1] https://github.com/sandflow/imscJS TTML is based on XSL, which is based on CSS, and so the mapping has been straightforward. [ed.: I am not sure what you mean by "does not fit well", perhaps you can elaborate.] The most significant challenge has been supporting two features (linePadding and multiRowAlign [2]), which are not supported in CSS, but have been identified as essential to captioning in Europe by the TTWG (and EBU). [2] https://www.w3.org/TR/ttml-imsc1/#linepadding I would think that features that are important to subtitling/captioning should be considered for CSS, regardless of the ultimate timed text format (TTML, WebVTT, etc...) Best, -- Pierre On Wed, Nov 23, 2016 at 3:33 PM, 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-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)
Received on Monday, 12 December 2016 05:05:49 UTC