ISSUE-345: tts:overflow - ambiguous language about region extent [TTML 1.0 (Editorial)]

ISSUE-345: tts:overflow - ambiguous language about region extent [TTML 1.0 (Editorial)]

http://www.w3.org/AudioVideo/TT/tracker/issues/345

Raised by: Glenn Adams
On product: TTML 1.0 (Editorial)

The normative text in TTML1 8.2.15 (tts:overflow) ", and region composition and layout must be performed as if the region's width and height were unconstrained" has been misinterpreted (based on its surface, but not intended meaning) to mean that a region's size is automatically extended to contain overflowed content. Since it is not the intent of this language to override or contradict the existing semantics of the overflow property of XSL 1.1 or CSS2.1, a clarifying note is needed (in errata and eventual incorporation) as follows:

<quote>
Note:

This attribute has no impact on presentation processing when no overflow condition applies. Furthermore, an overflow condition only applies in either (or both) of two specific contexts: (1) when tts:wrapOption is noWrap and the bounding box of some descendant glyph area overflows (extends outside of) the containing region's nominal content area extent in the inline progression dimension, or (and) (2) when the bounding box of some descendant line area overflows (extends outside of) the containing region's nominal content area extent in the block progression dimension, where the nominal content area extent in the inline and block progression dimensions is determined by the computed values of the tts:extent and tts:padding style properties of the containing region. Furthermore, when an overflow condition applies, it is not intended that the effective extent of the region be modified for the purpose of presentation processing. For example, the area painted with the region's background color is not extended in ether dimension to enclose the overflowed content.

Note that, in particular, the normative text in the previous paragraph "region composition and layout must be performed as if the region's width and height were unconstrained" refers to the process of determining the effective extent and origin of descendant line areas produced in either (or both) of the two overflow contexts described here, and is not intended to imply that the region extent is altered for the purpose of determining the region's padding area insets or the extent of its background color. More specifically, the normative language above is not intended to override or contradict the semantics of [XSL 1.1], § 7.21.2, or of [CSS2], § 11.1.1, on which the former is based.
</quote>

A fix is also needed in TTML2, which is best obtained by simply removing the problem language ", and region composition and layout must be performed as if the region's width and height were unconstrained", this language not being necessary and potentially generating mis-interpretations. In TTML, when it comes to style semantics, one should first determine the XSL-FO (and CSS) semantics, and then determine if the TTML semantics intentionally overrides or modifies these semantics. If the answer is no, then the XSL-FO/CSS semantics apply in whole. This is the criteria in the case of this particular issue: no override or modification of XSL-FO/CSS overflow semantics was intended.

Received on Wednesday, 17 September 2014 04:10:34 UTC