Re: Call for Wide Review of TTML2 WD for CSS Working Group

> On Jul 12, 2017, at 21:32, Thierry MICHEL <tmichel@w3.org> wrote:
> 
> Dear CSS Working Group,
> 
> The W3C Timed Text Working Group has recently published a new working
> draft of the Timed Text Markup Language 2 (TTML2).
> 
> https://www.w3.org/TR/2017/WD-ttml2-20170630/

These are just my comments, I am sending them here without the TTWG in CC as I do not know if this is a consensual position in the CSS WG or not. If we do have consensus on this, I am happy to replace all instances of "I think" and the like by "we think" or "the css wg thinks" and to send it as a group.

Disclaimer 1: I neither have the time nor the expertise to review the entire specification. I mainly looked at the parts that relate to styling and layout.

Disclaimer 2: I am not aware of the history of this technology, and some (or all) of my comments may be invalidated once that is taken into account.

The mechanism TTML defines for styling and layout is superficially similar, but not identical to CSS properties and values. I believe this similar-but-different situation is unfortunate. Some details:

1. While many tts:* attributes have the same name as a css property, the acceptable values for quite a few of these are different from the css equivalent.
  * Sometimes TTML accepts a subset of what CSS does (e.g. tts:backgroundRepeat takes a single value while css background-image takes a list)
  * Sometimes TTML accepts a superset of what CSS does (in TTML, <length> always includes <percent> while in css, it does not and some properties that take a <length> do not take a <percent>)
  * Sometimes it accepts different values, neither subset nor superset (tts:display accepts fewer values than css's display property, but it does have an auto value that css does not have)
  * Sometimes TTML conflates into one attribute things that CSS splits into several properties (e.g. ts:border includes borderRadii, while in css border-radius is not part of the border shorthand).
  * Sometimes TTML matches the syntax of earlier CSS drafts which have been replaced by a different syntax and semantics as the draft has matured (e.g. tts:writingMode vs css's writing-mode property).

2. TTML has some attributes which accomplish things that css also solves with unrelated properties whose behavior is different. (e.g. tts:displayAlign does alignement in the block direction, which is differently addressed by css properties like align-content, align-self, and align-items).

3. For attributes/properties where TTML and css do match at the syntactic level, TTML does not defer to CSS the definition of the behavior, but has its own normative statements about their effect. These normative statements are not always compatible with the corresponding thing in CSS (e.g. tts:lineHeight defines the inter-baseline separation, which is not what the css line-height does). TTML does claim that its model comes from XSL-FO rather than CSS, so this may explain part of the difference, but nonetheless multiple attribute are normatively defined in TTML in ways that do conflict with CSS (I did not review whether they also conflicted with XSL-FO, but given that there are standalone normative statements, I would be surprised if there was not some level of tension).

This does not in itself make TTML styling & layout necessarily a bad model in isolation, but it makes it doubtful that a CSS engine can be effectively used to render it with any level of fidelity. Given that CSS is the main client-side layout technology in Browsers, this is regrettable. It either means browser would have to have a completely separate style and layout engine just for TTML (or a meta engine that is flexible enough to handle both), or that they will simply not support it. My expectation, which seems supported by at least some browser vendors [1][2], is that they will chose not to support it.

Given that most of what TTML does in terms of layout and styling is already available via standard CSS, and that there is no obvious reasons to think that the things it has that CSS does not could not be added to CSS, this is unfortunate.

The fact that TTML has a mechanism that is different from CSS selectors and the cascade to associate styles with elements does not seem as problematic as the mismatch between TTML style attributes and css properties. Had the layout engine worked the same, the fact that properties get assigned to elements differently could be overcome comparatively simply. Nonetheless, it was not fully clear to me why using the CSS cascade would not be have been appropriate. Maybe there is a justification, but otherwise, reusing an existing mechanism would have been preferable. Similarly, though the abstract syntax is similar (but not identical as discussed above), it is not clear to me what the benefit of having camelCased properties and values over hyphenated properties and values is. Not reusing the concrete CSS syntax as-is is not necessarily a deal breaker on its own, but reusing it would also seem preferable.

Moreover, the normative descriptions of tts:* attribute are generally shorter than their css equivalents (e.g. see tts:writingMode vs css's writing-mode for a rather extreme example), making me doubt that there is sufficient detail for fully interoperable implementations.

In conclusion, the styling and layout aspects of TTML make me strongly doubt it is well suited for client side use on the web. Whether its other aspects are well suited or not, and whether TTML can be well suited to non web contexts is out of scope for this review.

Finally, I think it would be useful for the Timed Text Working Group to give feedback to the CSS WG about things its members think are needed for layout that are not adequately covered by CSS, so that CSS can be improved to handle these use cases.

—Florian

[1] https://lists.w3.org/Archives/Public/www-archive/2013May/0034.html
[2] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/vXuOTK5M0hM

Received on Friday, 14 July 2017 05:55:18 UTC