Improve interoperability of tts:direction on tt:p with CSS3 implementations.

[nigelmegitt]

Arising from #1211 change tts:direction as applied to p elements so that it additionally sets the inline progression direction, and overrides the inline progression direction set by tts:writingMode, if set.

This change makes TTML match the behaviour of ~XSL-FO~ SVG and CSS.

[Updated 2020-10-14 to remove XSL-FO from the behaviour match, but add SVG]

[skynavga]

N.B. the editor does not agree with the above comment that XSL-FO licenses or even implies that the XSL-FO direction property has any impact on the inline progression direction of a FO block area (as, for example, might be generated by the tt:p conceptual layout model). Indeed, he believes the exact opposite (that it does not have any impact, as a close reading of XSL-FO 1.1 §7.29.1 clearly indicates). The only context where XSL-FO applies direction to the control of inline-progression-direction is in the case of inline-generating FO objects and then only when paired with the bidi-override property (see fo:bidi-override, the only FO element to which the direction property applies).

[nigelmegitt]

Archaeological note: Tracker issue 414: tts:direction should apply independently to paragraph (p) was migrated to #142 which was resolved in 2c12004d4d78d52fd986fe32929a3974dcf3769a

[nigelmegitt]

To @skynavga 's response to my earlier assertion about XSL-FO's specification of the direction property, I tried adjusting @tairt 's XSL-FO gist to do as I initially read the spec to allow, i.e. change the inline progression direction by using the direction attribute together with unicode-bidi="embed" in an fo:bidi-override element. Rendering the result with the only freely available XSL-FO processor I could find, FOP, it behaves as per @skynavga's interpretation, i.e. it does not modify the start edge of the block to match the more locally specified inline progression direction.

At least in the case of FOP, then, it is not possible to use direction to modify the start and end edges set by the TTML region's equivalent fo:block-container in its writing-mode attribute.

In my initial reading of XSL-FO I did indeed fail to notice that although the wording in §7.29.1 talks about overriding the inline-progression-direction and affecting the writing direction of blocks, this appears to be an oddity (maybe an inconsistency?) in the specification, since it is only applicable on fo:bidi-override whose children are inlines, and it doesn't appear to inherit down into inline blocks. Thank you @skynavga for pointing this mistake out to me.

I've updated the initial comment on this issue to reflect this change of understanding.

Nonetheless, these data points have limited value. It seems highly unlikely today that anyone is actually using an XSL-FO processor to present TTML content (please say if you do!). Rather, using SVG or HTML+CSS are far more likely implementation strategies. In my experiments (SVG codepen) both of those set both the inline alignment edge and the paragraph embedding level together according to the direction property.

Changing the currently specified behaviour would therefore likely be helpful to implementers as well as being a breaking change for any implementations that behave strictly now (I'm wondering about the gstreamer TTML implementation, for example).

[andreastai]

@nigelmegitt

Nonetheless, these data points have limited value. It seems highly unlikely today that anyone is actually using an XSL-FO processor to present TTML content (please say if you do!).

At least XSL-FO engines have been used to create reference material (e.g. https://github.com/IRT-Open-Source/irt-ebu-tt-d-application-samples). Although there was is no use case in that material where tts:direction applies to the <p> element. We just need to be sure that there is no normative test material of other organizations that has this test case and the implementation contradicts the "CSS alignment".

In general we have the problem that on the one hand XSL-FO is the conceptual layout model of TTML but it is not used as implemantation context. On the other hand, we need to be careful to inject logic from other layout models with the purpose of making current implemenation easier but possibly undermining the coherency.

[nigelmegitt]

@tairt I would agree with your points, but the fact that they are rather hypothetical weighs against them in my view: if we had a concrete example of either an organisation's test case that depends on the XSL-FO behaviour for this feature, or of some coherency issue, that would strengthen the argument against making the change.

Unfortunately I do not believe it would be possible to examine all organisations' test cases; we are dependent on people telling us if this would cause a problem.

[skynavga]

I think it is important to point out that the CSS3 behavior that folks are pointing out was not present in CSS2.0, which was current when XSL1.0 and XSL1.1 was created. In other words, the behavior you are attempting to shoehorn in at this juncture only came about in CSS with the introduction of recent changes introduced by CSS3 Writing Modes, and represent a backwards incompatible change w.r.t. CSS2 semantics.

[nigelmegitt]

@skynavga that's true, or to put it another way, we are shoehorning in behaviour that has been shoehorned into CSS already. I think the argument comes down to weighing up the cost of following the CSS & SVG model against the cost of not following that model.

[skynavga]

@nigelmegitt I would like you to be more precise. You keep referring to the CSS & SVG model. But in fact you are referring to the CSS3 & SVG+CSS3 model, which is not backwards compatible with the CSS2 & SVG+CSS2 model or the XSL or TTML{1,2} models. I haven't evaluated the proposed PR yet, but to the extent that it is a non-backwards compatible change will be a BIG DEAL and will need to be made very prominent and very likely kick it out of consideration in a TTML2 context.

[nigelmegitt]

Thank you for pulling me up on that @skynavga , yes, I mean the current CSS3 & SVG+CSS3 model.