The width of content elements' areas is unclear, especially looking at the examples

[plehegar]

The size of content elements relative to their parent elements and generated content elements is unclear. It is neither specified in chapter 10.2.1 Style Attribute Vocabulary nor in chapter 8.1 Content Element Vocabulary. It perhaps is specified in chapter 11.3.1.4 Synchronic Flow Processing however there are no forward references directing the reader there. Even if it is in fact specified by a normative reference to XSL-FO and/or CSS, it would be helpful to add non-normative Notes where the information is most relevant, i.e. on style attributes whose effect is bounded by the applicable rectangular area.

The terms "block display", "inline display" and "inline block display" are usefully defined in TTML2 but those definitions are not referenced everywhere they apply.

Specifically, the implementation of the tts:backgroundColor, tts:backgroundImage and tts:border style attributes depends on the correct calculation of the rectangle to which they apply, and that rectangle is computed differently for spans than for the other content elements: only for spans is the size in the inline progression dimension related to the text content width; all the other elements' size in the inline progression dimension relates to the parent element's content rectangle minus any padding applied.

The example for tts:backgroundColor is ambiguous and possibly misleading in this respect, because the width of the text has been chosen to be exactly the same as the width of the content area of the p that is coloured purple, making it appear to the casual observer that the purple box is shrunk to the maximum width of the inline areas generated for the text.

Proposed resolutions:

1. EITHER include normative text that specifies how the calculation of the rectangle to which the above listed attributes apply differs between spans and other content elements OR (if somehow the normative text is already strong enough) add non-normative notes to each attribute calling out the difference, or add the note to the introductory part of chapter 10.2 and then reference it from the attributes.
2. Add a diagram showing the width and height calculation (possibly this relates also to the resolution for Issue-302) that applies to each content element, and reference it from tts:backgroundColor, tts:backgroundImage and tts:border. This could be in the introductory part of chapter 10.2 for example.
3. Change the example for tts:backgroundColor to make it use a longest line length that is shorter than the width of the content area of the parent p element, or add a new example or a second p where that is the case.
4. Ensure that the examples for tts:border do not reproduce the ambiguity.

(raised by Nigel Megitt on 2015-03-26)
From tracker issue http://www.w3.org/AudioVideo/TT/tracker/issues/380

[nigelmegitt]

Reviewing this, the issue remains open, and one of the reasons is that the spec does not normatively make the link between the CSS box layout algorithm and the content elements body, div, p, span and br. Defining these normatively as part of #127 could be a way to address this for example.

[skynavga]

Regarding the previous comment, TTML does not make any use of the CSS box model per se. Rather, it makes normative reference to XSL-FO's area model, which in some cases, is based in part on CSS semantics.

I believe it is impractical (and undesirable) to either adopt proposed resolutions 1 or 2 listed above. I would not object to improving either the example code or rendition used with tts:backgroundColor or tts:border. However, at present, we have no proposed PR that provides improved examples, so I am closing and marking for ttml.next. If someone wants to propose a PR, feel free to re-open this issue.

[nigelmegitt]

Closing in the absence of a PR and in the absence of discussion is inappropriate. Reopening. We have not yet assessed for each open issue if it should be moved to ttml.next, so removing that label.

[skynavga]

Moving off Editor's WR list due to lack of PR.

[nigelmegitt]

I will raise a PR for this to change the examples on tts:backgroundColor and tts:border so that they are less ambiguous, as per proposals 3 and 4 above.

[nigelmegitt]

I've raised a pull request for this as per options 3 and 4 and added back to the Editor's WR list.