Interaction between tts:writingMode and tts:direction on paragraph element.

[palemieux]

TTML2 specifies:

When applied to a p element, the computed value of tts:direction explicitly establishes the paragraph level as specified by [UAX9], §4.3, Higher Level Protocol HL1.

It is unclear how this interacts with tts:writingMode. Specifically:

• are there any cases where tts:direction and tts:writingMode should conflict on <p>? In other words, does specifying tts:direction="ltr" ever make sense if tts:writingDirection="rl? CSS does not allow this inconsistency.

• what does tts:direction mean when the IPD is vertical? UAX #9, clause 6.2 implies that tts:direction should affect character rotation, but, again, this is ignored by CSS.

• the Direction003.html test case implies that specifying tts:direction="rtl" on <p> changes the IPD.

• XSL specifies that If the "direction" property is explicitly specified on the same formatting object the value of the "direction" property will override the inline-progression-direction set by the "writing-mode".

I suggest considering the following clarification:

when specified on <p>, tts:direction sets the inline progression direction, overriding that set by tts:writingDirection. In the case where the block progression direction is horizontal, tts:direction="ltr" specifies a top-to-bottom inline progression direction whereas tts:direction="rtl" specifies a bottom-to-top inline progression direction.

[fantasai]

In the case where the block progression direction is horizontal, tts:direction="ltr" specifies a top-to-bottom inline progression direction whereas tts:direction="rtl" specifies a bottom-to-top inline progression direction.

Idk that TTML uses it, but for writing-mode: sideways it is the opposite: ltr is bottom-to-top.

when specified on <p>

I'm unfamiliar with the TTML markup and inheritance model, but if you have higher-level elements, shouldn't tts:direction inherit from those also?

Fwiw, a much earlier property model in CSS had writing-mode as a shorthand for both block-direction and direction properties. (They were split out because vertical vs horizontal writing is a presentational preference, whereas bidi direction is describing the content.) If you need to preserve tts:writing-modes’s ability to set the bidi direction when tts:direction is not set, then you could consider a similar model, where tts:writing-mode sets both direction and writing-mode and tts:direction sets only direction. But if there's no compat risk, I might suggest taking the same model as CSS and using only tts:direction for RTL.

[skynavga]

@palemieux I see no inconsistency here. The text of XSL 1.1 §5.8 makes it clear that inline progression direction at the block level is determined by writing mode, and within inline formatting objects by a combination of the Unicode Bidi Algorithm and the tts:unicodeBidi and tts:direction properties. The semantics of tts:direction clearly specify that they are applied only in two cases (1) when applied to p to determine the default paragraph level and (2) when used in combination with tts:unicodeBidi. Note also that an author is free to employ Unicode Bidirectional Control characters as an alternative to or in addition to style markup, e.g., instead of using tts:unicodeBidi and tts:direction properties.

If an author specifies, e.g., that a region has tts:writingMode="rl" but then specifies a tts:direction="ltr" on a p in that region, then there is no semantic (or processing) inconsistency: you have a Left-to-Right paragraph in a outer Right-to-Left region. This is perfectly well defined as far as UAX#9 and XSL formatting semantics are concerned.

The issue regarding vertical inline progression modes is also well defined as far as I'm aware, though it would be a bit awkward since we don't define the vertical equivalent of horizontal "rl" modes, i.e., "btrl" and "btlr", the reason being that the market hasn't asked for one. Technically, one could do it with "tbrl" or "tblr" writing modes and then use tts:direction="rtl" on paragraphs, but I know of no implementation that explicitly supports (or has tested) this combination. TTPE hasn't.

I would object to the proposed (alleged) clarification, which in my mind confuses the matter, since it does not "override" writing mode; rather, tts:direction on p does exactly (and only) what it already says it does in the spec:

When applied to a p element, the computed value of this property explicitly establishes the paragraph level as specified by [UAX9], §4.3, Higher Level Protocol HL1.

[palemieux]

If an author specifies, e.g., that a region has tts:writingMode="rl" but then specifies a tts:direction="ltr" on a p in that region, then there is no semantic (or processing) inconsistency: you have a Left-to-Right paragraph in a outer Right-to-Left region.

Will the IPD be left-to-right in the block created by the paragraph?

[cconcolato]

@skynavga Here is the rendering I get with TTPE 7.1-SNAPSHOT

Do you confirm that it is the result you'd expect? I may have misconfigured TTPE. If not, it seems counter-intuitive when the text says "This text is displayed right to left."

I see that Direction003 is reported in the Implementation Report for TTML1, unfortunately it is not in the ttml1-tests repo. The IR says that 2 implementations passed it: "W3C / HTML5/JS" and "MS / Silverlight TimedTextPad". Are these implementations still around? I'd be curious to see their rendering. It's a pity we don't have the matching images (do we?).

[nigelmegitt]

@cconcolato Direction003 got moved to https://github.com/w3c/imsc-tests/blob/master/imsc1/ttml/direction/Direction003.ttml - a lot of useful TTML1 tests got moved into that repo. The render at https://github.com/w3c/imsc-tests/blob/master/imsc1/png/Direction003/0.000000.png does indeed differ:

[cconcolato]

For reference, @palemieux found this: https://www.w3.org/2008/12/dfxp-testsuite/web-framework/START.html
When you try Direction003 with the only player that was passing according to https://www.w3.org/2009/05/dfxp-results.html, i.e. the HTML5 player, it gives the following:

[skynavga]

@palemieux re: #1211 (comment), the block-progression-direction and inline-progression-direction traits of the block level reference area generated by the region are determined by the ttp:writingMode property on that region; the block-progression-direction and inline-progression-direction traits of each block area generated by a p element associated with that region inherit (are assigned) the same block-progression-direction and inline-progression-direction traits as its associated region's traits; the tts:direction property on p has no impact on these semantics; however, for the purpose of determining the inline-progression-direction of character descendants of a paragraph, the Unicode Bidi Algorithm does apply, and tts:direction on p sets the Default Paragraph Bidi Level for the purpose of running UAX#9 on the paragraph's character content. Once UAX#9 has been run, you end up with directionally resolved text runs which allow you to assign resolved inline-progression-direction traits to generated inline area objects that compose each line area generated by the paragraph.

To attempt to answer more succinctly, the IPD of the paragraph's generated blocks will be RTL, and, therefore, start will mean left. OTOH, the IPD of inline area descendants of these blocks may be RTL or LTR depending upon the result of UAX#9 processing, which includes the value of tts:direction on p as an input parameter.

[palemieux]

the IPD of the paragraph's generated blocks will be RTL, and, therefore, start will mean left. OTOH, the IPD of inline area descendants of these blocks may be RTL or LTR

Two questions come to mind:

• what are the use cases where the IPD of a <p> would be rl but the IPD of its inline area descendants would be lr?

• Can a <p> have non-inline area descendants?

[skynavga]

the IPD of the paragraph's generated blocks will be RTL, and, therefore, start will mean left. OTOH, the IPD of inline area descendants of these blocks may be RTL or LTR

Two questions come to mind:

• what are the use cases where the IPD of a <p> would be rl but the IPD of its inline area descendants would be lr?

What is the relevance of use case to this issue?

• Can a <p> have non-inline area descendants?

The XSL-FO model has p generating line areas which are block areas, which, in turn, have inline area descendants, some of which may be inline block areas, which look like block areas in an inline context.

[skynavga]

@cconcolato re: #1211 (comment), I haven't run this against TTPE myself to verify (will do so later today), but if my results confirm this, then it would be a bug or incomplete feature implementation in TTPE, since the content of Direction003.xml appears to be reasonable from a quick viewing. However, that content does indeed raise another (unmentioned) ambiguity about the semantics of tts:direction on p; namely, when applied to p, it may have one of two interpretations depending on whether there is an accompanying tts:unicodeBidi style: if tts:unicodeBidi is specified, then it should have sense (2) as indicated in the first paragraph of §10.2.12, but if not specified, should have sense (1).

[skynavga]

@nigelmegitt re: #1211 (comment), the alignment is bad, i.e., the outer paragraph block should be right aligned since the default for writing mode is lr; changing the default paragraph bidi level for the purpose of UAX#9 processing doesn't change the assigned writing mode: inline progression direction on the paragraph block area is still left to right

[palemieux]

The XSL-FO model has p generating line areas which are block areas, which, in turn, have inline area descendants, some of which may be inline block areas, which look like block areas in an inline context.

Ok. Each line area extend from one to other edge of the the parent block along the inline axis and tts:direction controls the IPD within each line area, right?

If so, in what circumstances will the rendering of the following two snippets differ?

<region xml:id="a" tts:writingMode="lr"/>
...
<p region="a">
Some text
</p>

and

<region xml:id="a" tts:writingMode="rl"/>
...
<p region="a" tts:direction="ltr">
Some text
</p>

[css-meeting-bot]

The Timed Text Working Group just discussed (AOB) Interaction between tts:writingMode and tts:direction on <p> w3c/ttml#1211, and agreed to the following:

• SUMMARY: Continue discussions on the issue thread for the time being.

The full IRC log of that discussion

<nigel> Topic: (AOB) Interaction between tts:writingMode and tts:direction on <p> w3c/ttml#1211
<nigel> github: https://github.com//issues/1211
<nigel> Nigel: One thing I note about this is Direction003 used to be in TTML tests and has moved
<nigel> .. to IMSC tests and that has confused a couple of people independently recently.
<nigel> .. Does anyone else feel that an explainer for Where to Find TTML Tests would be a useful document?
<nigel> Pierre: Looking at Glenn's comments, he thinks TTPE's presentation is wrong.
<nigel> Nigel: He thinks the reference render is wrong though.
<nigel> Pierre: [explains how the lines in the p all use the whole width so the layout direction - scribe failure]
<nigel> Nigel: Is textAlign used in the test?
<nigel> Pierre: It would be weird for textAlign to be affected by writingMode.
<nigel> .. I think we need an answer from Glenn.
<nigel> Nigel: How do you know the line areas cover the whole width? That seems unusual.
<nigel> Pierre: Exactly.
<nigel> Pierre: Maybe we need to get everyone around the table for that with examples.
<nigel> Nigel: I'm sure if we schedule this for a meeting and invite Glenn then we can gather him and
<nigel> .. anyone else interested.
<nigel> Andreas: I planned also to look into this issue so please keep me posted if you schedule a
<nigel> .. separate meeting.
<nigel> Nigel: My default here would be to use one of these TTWG weekly calls if possible.
<nigel> Nigel: Let's allow the conversation to continue on the issue thread, and convene a meeting
<nigel> .. perhaps in 2 weeks time, if there are outstanding questions.
<nigel> Pierre: Alright.
<nigel> SUMMARY: Continue discussions on the issue thread for the time being.

[skynavga]

@palemieux re: #1211 (comment), it is not accurate to say that

tts:direction controls the IPD within each line area

however, it would be accurate to say that

tts:direction may influence the inline progression direction† within inline areas descendants of line areas

more specifically, controls is too strong a word, since it is only one of a number of possible factors that influence the determination of inline progression direction, others being:

• the presence of Directional Formatting Characters in outer scopes (up to p level) and inner scopes (within the inline generating element);
• the Bidirectional Character Types and context of characters of specific Bidirectional Character Types in outer scopes (up to p level) and inner scopes (within the inline generating element);
• the computed Paragraph Level‡ determined for UAX#9 paragraphs

†The term IPD refers to inline progression dimension, not inline progression direction.
‡A UAX#9 paragraph does not necessarily correspond with a TTML p element; i.e., a p element can map to a sequence of UAX#9 paragraphs (separated by 0x2029 PARAGRAPH SEPARATOR characters).

Regarding the second part of re: #1211 (comment), firstly, these two examples have nothing to do with your first question which I answered above, since these examples do not produce any differences in the inline progression direction of the inline area descendants of the outer block area generated by p for the following reason:

In both of these examples, the UAX#9 paragraph level will be left to right, the text content doesn't change, and it is, with the exception of one WS character, all L class characters. The paragraph level is left to right in both cases due to:

1. in the first example, tts:direction on p inherits from region which computed value of ltr is determined from the inline progression direction of tts:writingMode on region;

2. in the second example, tts:direction on p is explicitly specified as ltr;

therefore, the inline progression direction of every inline area generated by p in both examples will be the same value: left to right.

However, notwithstanding the above, there will be a significant visual difference, namely, the text alignment of the two paragraphs, neither of which specify an explicit value for tts:textAlign, and, therefore, the computed value of the text-align trait on the block areas generated by the p elements will be start, but, the used value will be left in the first example, but right in the second example. The reason for this is that the text alignment of a paragraph is determined by the inline progression direction that applies to the outer block level areas generated by the paragraph (irregardless of the inline progression direction of descendant inline block areas), and the first example has a writing mode of lr while the second example has a writing mode of rl.

As a final note, the initial description of this issue has a misleading statement when it suggests that the following text in [XSL-FO 1.1] §7.2.9 applies in the current context. In fact it does not apply here, since this cited text is discussing cases where one can specify both writing-mode and direction on the same element, and that only occurs in TTML in the case of the region element, and we already have language for dealing with this possibility (of having both specified and in conflict), namely, see https://w3c.github.io/ttml2/index.html#style-attribute-direction-special-semantics.

XSL 1.1 §7.2.9

To insure consistency with the "writing-mode" property, the "direction" property is initialized to the value that sets the same inline-progression-direction as is set by the "writing-mode" property whenever that "writing-mode" property sets that direction. If the "direction" property is explicitly specified on the same formatting object the value of the "direction" property will override the inline-progression-direction set by the "writing-mode".

[cconcolato]

Rendering by TTPE (7.1 Snapshot) of the above examples:

<?xml version="1.0" encoding="UTF-8"?>
<tt:tt xmlns:tt="http://www.w3.org/ns/ttml" xmlns:ttp="http://www.w3.org/ns/ttml#parameter" xmlns="http://www.w3.org/ns/ttml" xmlns:tts="http://www.w3.org/ns/ttml#styling" xmlns:ttm="http://www.w3.org/ns/ttml#metadata" ttp:contentProfiles="http://www.w3.org/ns/ttml/profile/imsc1.1/text" xml:lang="en">
  <head>
    <styling>
      <initial tts:color="white"/>
    </styling>
    <layout>
      <region xml:id="a" tts:writingMode="lrtb" tts:extent="80% 80%" tts:origin="10% 10%"/>
    </layout>
  </head>
  <body>
    <div>
      <p begin="0s" end="10s" region="a">
      Some text
      </p>
    </div>
  </body>
</tt:tt>

<?xml version="1.0" encoding="UTF-8"?>
<tt:tt xmlns:tt="http://www.w3.org/ns/ttml" xmlns:ttp="http://www.w3.org/ns/ttml#parameter" xmlns="http://www.w3.org/ns/ttml" xmlns:tts="http://www.w3.org/ns/ttml#styling" xmlns:ttm="http://www.w3.org/ns/ttml#metadata" ttp:contentProfiles="http://www.w3.org/ns/ttml/profile/imsc1.1/text" xml:lang="en">
  <head>
    <styling>
      <initial tts:color="white"/>
    </styling>
    <layout>
      <region xml:id="a" tts:writingMode="rltb"  tts:extent="80% 80%" tts:origin="10% 10%"/>
    </layout>
  </head>
  <body>
    <div>
      <p begin="0s" end="10s" region="a" tts:direction="ltr">
      Some text
      </p>
    </div>
  </body>
</tt:tt>

(I had to modify the values of writingMode to add tb because TTPE would not recognize it)

[skynavga]

So, in this case, TTPE implements the intended behavior.

[andreastai]

I agree with most what @skynavga responded to @palemieux in #1211 (comment). But the mixture of TTML specifics, CSS and XSL-FO makes it complex. So, I have still some questions. If I try to bring the pieces together I get no consistent picture.

My interpretation:

A region maps in XSL-FO to a fo:block-container object. It is the only TTML element that can map to it. An fo:block-container establishes a reference area. It is the only fo-object that is used in the derived TTML XSL-FO layout model that can establish a reference area. writingMode in XSL-FO applies only to objects that create reference areas and establishes the directionality of the edges of these reference areas, in our case for the start and end edges. Therefore in TTML writingMode can only be applied to a region. So far I agree. But I wonder if direction specified on a region also changes the directionality of the edges of a reference area. I think that XSL-FO is a bit ambiguous here. On the one hand as @skynavga mentions, XSL 1.1 §7.2.9 states:

If the "direction" property is explicitly specified on the same formatting object the value of the "direction" property will override the inline-progression-direction set by the "writing-mode".

But later it also says in the same listing:

The "direction" property only changes the inline-progression-direction and is used primarily for formatting objects that generate inline-areas that are not also reference areas. Use of the "direction" property for other formatting objects is deprecated in this specification.

"direction" as property can also not be applied to a fo:block-container (of course this does not exclude specification on it).

I think the first point of the XSL-FO specific additions in XSL 1.1 §7.2.9 may give a hint:

The specific use of "direction" and "unicode-bidi" on inline objects is to set the inline-progression-direction to be used by the Unicode BIDI algorithm. This direction may override the inline-progression-direction determined by the current writing-mode and the implicit direction determined by the Unicode BIDI algorithm.

My interpretation is that "direction" does not intervene with the directionality of the edges set by writingMode (e.g. with the question if start is left or right) and only plays a role in the application of the Unicode BIDI algorithm. My tests with an XSL-FO reference formatter confirm this assumption.

Regarding the test cases: I propose to use more complex samples that combine characters with strong, weak and neutral bidi_types e.g. the text 1) Some text. That also shows how the character stacking is influenced by writingMode, direction and unicode-bidi.

[palemieux]

My interpretation is that "direction" does not intervene with the directionality of the edges set by writingMode (e.g. with the question if start is left or right) and only plays a role in the application of the Unicode BIDI algorithm

That was my initial interpretation as well. I have however since run into two issues (as described at #1211 (comment)):

• this contradicts the stated intent of Direction003.html
• there is no mapping to CSS as far as I know

[skynavga]

My interpretation is that "direction" does not intervene with the directionality of the edges set by writingMode (e.g. with the question if start is left or right) and only plays a role in the application of the Unicode BIDI algorithm

That was my initial interpretation as well. I have however since run into two issues (as described at #1211 (comment)):

• this contradicts the stated intent of Direction003.html
• there is no mapping to CSS as far as I know

How does it conflict with Direction003.xml (not html)? The text of Direction003.xml should indeed be right to left because of the tts:unicodeBidi='override' combined with tts:direction='rtl'. There should be no difference between the behavior of Direction003.xml and

<p>&#x202E;This text is displayed right to left.&#x202C;</p>

and

<p><span tts:unicodeBidi="override" tts:direction="rtl">This text is displayed right to left.</span></p>

Please ignore the behavior of TTPE for Direction003.xml as there is a bug at work.

[palemieux]

Please ignore the behavior of TTPE for Direction003.xml as there is a bug at work.

Thanks for clarifying.

[andreastai]

Note that this comment was updated based on below comments by @nigelmegitt and @skynavga. Thanks for that!

I created samples in TTML, XSL-FO, HTML/CSS. Driving questions:

1. Result if @tts:direction is specified on <tt:region> or <tt:p>?
2. Mapping to XSL-FO and HTML/CSS?

Fictional use case: a sports program in Arabic. In a three-row subtitle a coach of an English team is cited as follows:

The English coach has two goals:
"1) We win the championship!
2) We play fair!"

The first sentence of the subtitle is written in Arabic.

The subtitle should be aligned at the right edge of the video. Relative values should be used to set in TTML the text alignment.

Cases

I covered three cases:

1. @tts:direction is not specified
2. @tts:direction is specified on a <region> element
3. @tts:direction is specified on the <p> element

Each row of the subtitle is wrapped in a <p> element. All <p> elements are in the same region. For the <region> element the @writingMode attribute is set to rltb. This results in a right-to-left inline progression direction and a top-to-bottom block progression direction.

Case 1: @tts:direction is not specified

No measure is taken to adapt to the bi-directionality of the subtitle. @tts:direction is not specified explicitly.

• TTML as Gist
• XSL-FO as Gist*
• HTML/CSS
  • HTML/CSS on CodePen
  • HTML/CSS as Gist

* The TTML to XSL-FO mapping is based on the samples in TTML2, 11.3.1.4 Synchronic Flow Processing. The XSL-FO rendering was checked with two XSL-FO formatters.

Case 2: @tts:direction is specified on a <region> element

The assumption is that the value of @tts:direction changes the inline progression direction in a way as if it would have been specified as part of the @tts:writingMode. If (as in the below case) the value of @tts:writingMode is rltb and @tts:direction is set to ltr then (following this assumption) the layout would be the same as if the value of @tts:writingMode would have been lrtb.

In the sample @tts:direction on the <region> element is inherited to all <p> in that region. Therefore it sets the paragraph embedding level or base direction for that <p> elements.

• TTML as Gist
• XSL-FO as Gist (UPDATED, 2020-08-19)
• HTML/CSS
  • HTML/CSS on CodePen (UPDATED, 2020-08-19)
  • HTML/CSS as Gist (UPDATED, 2020-08-19)

Case 3: @tts:direction is specified on the <p> element

@tts:direction is used to adapt to the bi-directionality of the subtitle and marks the English citation as a left-to-right sequence.

• TTML as Gist
• XSL-FO as Gist
• HTML/CSS
  • HTML/CSS on CodePen
  • HTML/CSS as Gist

Discussion

Case 1

This may be a typical example where a text sequence, with a horizontal writing direction opposite to the main horizontal writing direction, is just added, and no further adjustments are made. The TTML to XSL-FO mapping is straightforward. The writing-mode attribute of the <fo:block-container> element is set to rl-tb. The <fo:block-container> represent the TTML <region> element.

In CSS (as @fantasai mentioned in #1211 (comment)) the (inline-progression-)direction was factored out of the writing-mode property. To change the horizontal writing direction the direction property must be used. Because the default of the direction property is ltr for a left-to-right direction, it has to be set explicitly to rtl to achieve the same effect as in the TTML sample.

Case 2

For the fictional use case, it seems not a rational option but it is considered here to discuss the use of @tts:direction on <region>. A syntactic mapping to XSL-FO is not straightforward as @direction can not be specified on a <fo:block-container> element. @direction can only be specified on the <fo:bidi-override> element. <fo:bidi-override> can not be a child element of <fo:block-container>. Therefore the only way to achieve the same result as in TTML is to change the value of @writing-mode on <fo:block-container> from rl-tb to lr-tb. to wrap the text content of all <fo:block> elements in the <fo:block-container> with a <fo:bidi-override> element (see also case 3).

The mapping to CSS is straightforward as the direction property sets the inline progression direction. The value can be changed from rtl to ltr or direction can be omitted completely (because the default value of the direction property is ltr). The solution pattern is the same as in case 3 with the exception that it has to be applied to all HTML <p> elements that correspond to TTML <p> elements in that region.

Case 3

To adapt to the bi-directionality of the subtitle in TTML @direction needs to be set explicitly for the English citation. By the specification of @direction on the <p> elements with the English text with a value of ltr, the initial embedding level of the paragraph is set to a value for left-to-right and numbers, quotes and parenthesis appear as intended. The interpretation of TTML is that the tts:unicodeBidi default value does not need to change.

A TTML <p> element maps in XSL-FO to a <fo:block> element. An <fo:block> element can not have a @direction attribute*. An <fo:block> can have <fo:bidi-override> as a child element that wraps the inline content. But it is not sufficient to set @direction on <fo:bidi-override> to <ltr>. To set a new embedding level @unicode-bidi on <fo:bidi-override> needs to be set explicitly to embed. Otherwise, the default value normal of @unicode-bidi would apply and the value of @direction would not have any effect.

The mapping to CSS requires to add a new <span> element that wraps the text content of the <p> element. A direction property with a value of ltr and a unicode-bidi property with the value of embed needs to apply to this <span> element.

A strategy where direction and unicode-bidi apply to corresponding HTML <p> elements would not work because this would also change the reference inline progression direction for the alignment of the text (which is not desired). The application of this strategy is documented in a CodePen and a Gist

* This is based on an interpretation of the XSL-FO spec and the testing with two XSL-FO formatters.

Thoughts

Overall the TTML specification seems to be consistent in it itself but the divergence from XSL-FO and CSS in some aspects may make the application of tts:writingMode, tts:direction and tts:direction difficult for implementers.

Therefore two changes could be discussed for a future version of TTML:

• Deprecate the use of the @direction attribute on a <region> element.

  • It has no direct mapping to XSL-FO.
  • It is hard to find a use case for it.

• Deprecate the use of the @direction on a <p>element.

  • @direction can be set in XSL-FO only on the inline element fo:bidi-override. From this perspective, it is very similar to a <span> element in HTML on which the direction and unicode-bidi CSS properties apply.
  • A direct mapping from the TTML attributes to CSS properties that apply to the corresponding <p> HTML elements may leed to false expectations regarding the rendering result.
  • In the logic of the unicode-bidi algorithm the @tts:unicodeBidi attribute needs to have the value embed to change the paragraph embedding level (instead of keeping the default value normal). Although this seems not an error it makes the application of this pattern difficult to understand.

[nigelmegitt]

@TairT Thanks for the detailed thoughts and sharing those carefully thought through examples. I have one question:

• Deprecate the use of the @direction attribute on a <region> element.

Did you notice that tts:direction does not apply to <region>, but only to <p> and <span>, therefore even if it is specified on a region, that is only used as the basis for inheritance down to the p and span level?

My understanding is that inheriting tts:direction from a region to derive its computed value is no different to specifying the same value on the p itself, so case 2 effectively becomes the same as case 3.

[andreastai]

Did you notice that tts:direction does not apply to , but only to

and , therefore even if it is specified on a region, that is only used as the basis for inheritance down to the p and span level?

Good point.

My understanding is that inheriting tts:direction from a region to derive its computed value is no different to specifying the same value on the p itself, so case 2 effectively becomes the same as case 3.

In case 3 you can specify @tts:direction on each <p> individually. In case 2 it applies to all <p> elements in that region.

[andreastai]

Based on #1211 (comment) by @nigelmegitt the rendering result for the case 2 TTML sample should be as documented in https://gist.github.com/tairt/78256a2e297f37e62f80dfb901b35e89.

@skynavga: Is this also your understanding?

[skynavga]

@TairT actually, neither image is correct; the 2nd image would be correct, were the Arabic letters properly joined, but they are not.

[andreastai]

@skynavga Thanks for having a look at it! I need to check where the error in the IMSC rendering occurred. Can you have a look at the new rendering: https://gist.github.com/tairt/78256a2e297f37e62f80dfb901b35e89#gistcomment-3422011 This formatting is the result of an XSL-FO input document where the block with the Arabic text is wrapped by an <fo:bidi-override> element where @direction is set to ltr and @unicode-bidi to embed.

[skynavga]

@TairT this last image https://gist.github.com/tairt/78256a2e297f37e62f80dfb901b35e89#gistcomment-3422011 appears correct as far as I can tell, though I can't be 100% for certain since I don't know the exact characters encoded in the source TTML file (if all of the content of the first paragraph were encoded using numeric character references, then I could check with certainty).

[skynavga]

@TairT I am assuming that the character that appears to be a COLON in the first paragraph is U+0030; I would want to check its logical position in the paragraph, e.g., whether it came first or last; I am guessing it may be at the logical end of the paragraph, which would place it on the right if the paragraph level is set to left-to-right due to inheriting tts:direction="ltr"

[skynavga]

@nigelmegitt

Can you think of any other reason why tts:direction needs to apply to p? Or any desirable effect that can only be achieved by applying tts:direction to p?

Frankly, I am amazed that anyone should dare to ask such a question. Must I walk you through the detailed semantics of UAX#9 §3.3.1 to demonstrate the meaning of

When applied to a p element, the computed value of this property explicitly establishes the paragraph level as specified by [UAX9], §4.3, Higher Level Protocol HL1.

Ask yourself what the behavior of UAX#9 is absent these semantics.

[css-meeting-bot]

The Timed Text Working Group just discussed Interaction between tts:writingMode and tts:direction on paragraph element. w3c/ttml2#1211.

The full IRC log of that discussion

<nigel> Topic: Interaction between tts:writingMode and tts:direction on paragraph element. #1211
<nigel> Pierre: I'd like to discuss how we get to a resolution on this; it is blocking resolution of an
<nigel> .. issue on imsc.js
<nigel> .. What about if we pick a time and date and say "we're going to solve this on this time and date"
<nigel> .. and ask everyone to come in with all the input needed etc. Then at the end we'll pick
<nigel> .. something.
<atai> q+
<nigel> Nigel: Would it make sense to gather our best knowledge and then raise it in the joint meeting
<nigel> .. with the CSS WG?
<nigel> Pierre: The answer should be yes, I'm hesitating because I am not a specialist in Arabic, Hebrew etc
<nigel> .. and there's a limitation on CSS; if that would be helpful I'm happy to ask the question on
<nigel> .. the CSS mailing list: explaining that direction in CSS sets the direction and writing mode,
<nigel> .. which Elika has already told me it is not a limitation but a feature.
<nigel> Nigel: Also something we should ask internationalisation?
<nigel> Pierre: We're unlikely to change CSS on this, there's a lot more international content in
<nigel> .. CSS than in TTML, so I doubt that we would change their mind without a compelling set
<nigel> .. of examples, which we don't. Glenn might be the best person to provide that, but he has
<nigel> .. not. I would tend to saying "do what CSS does" in the absence of the test content and
<nigel> .. examples to have a definitive opinion.
<nigel> Andreas: Which specification can we target for a change here?
<nigel> Pierre: TTML2, ultimately.
<nigel> ack a
<nigel> Andreas: OK, there was also the idea to constrain IMSC.
<nigel> .. The second thing is more a concern, from the current discussion, I think I understand
<nigel> .. how it was meant and how it should work, which may already help IMSC, and it should
<nigel> .. be possible to implement, but my concern is about how everything works together and
<nigel> .. that it is not explained enough in TTML. It is only in the reference implementation of TTPE
<nigel> .. and not in the spec.
<nigel> Pierre: To make things worse it is broken in TTPE too.
<nigel> github: https://github.com//issues/1211
<nigel> Pierre: So I am not super excited to consult CSS, we should use what's in browsers today
<nigel> .. and only ask for a change if we find a fatal flaw.
<nigel> Nigel: Are you making a specific proposal to remove the application of direction to p?
<nigel> Pierre: Yes, but I think it is not sufficient because setting it on span also changes the
<nigel> .. definition of start and end as Gary pointed out.
<nigel> .. I'm suggesting we pick a time, aim to solve within an hour and reach consensus.
<nigel> .. That gives everybody an opportunity to prepare.
<nigel> .. After or at TPAC, for example.
<nigel> Nigel: OK, TPAC dates are a little unclear, the obvious date range is 19-24 October.
<nigel> .. How about making it the main topic of our call on 8th October, the regular weekly call?
<nigel> Andreas: We may need to extend the call
<nigel> Nigel: I've created https://github.com/w3c/ttwg/issues/151 for that meeting.
<nigel> Nigel: Any specific points about this issue to raise while we're here?
<nigel> Cyril: Small point to clarify. Many times in our discussions we mentioned the semantic
<nigel> .. derivation and hinted that we could use the direction as a way to interpret the edge
<nigel> .. for padding and textAlign, and Glenn never responded to that part.
<nigel> .. My understanding is that they are not normative and that may be why he did not consider
<nigel> .. them at all. Is that true that they are not normative?
<atai> q+
<nigel> Nigel: I think so, need to check.
<nigel> Cyril: Then we should be careful - it may mean the CSS writing mode reference is not normative.
<nigel> Nigel: Yes, it's in Appendix N which Non-Normative.
<nigel> Andreas: I think this is really the point. You say that it is semantically derived from those
<nigel> .. specs, but don't explain a lot in the spec itself, and then make the derivation informative.
<nigel> .. TTML has not sufficient text to explain the layout in general. It leans on XSL-FO but a lot
<nigel> .. of it is informative not normative so it is really hard to understand how this works together.
<nigel> .. For an implementer what should they do? Where should they check how it should work?
<nigel> .. Even if it is not normative, but there is a semantic derivation, there is some kind of dependency.
<nigel> Nigel: N.2.1 says that it can be used for mapping to CSS or XSL, or to other things like SVG.
<nigel> .. I think the informative nature of these derivations is supposed to be a strength in that way,
<nigel> .. but sometimes it appears to be a weakness as well.
<nigel> Cyril: I just wanted to alert the group about that.
<nigel> Nigel: Thank you.

[skynavga]

From my reading of the IRC log, it does not appear that there is a shared understanding of the problem and whether or not there even exists a problem. My present opinion is there is no problem in TTML2 or CSS, but that there may be a problem in certain implementer's understanding of these specs and UAX#9 semantics.

[palemieux]

Firstly, I have not seen evidence that one cannot map* TTML2 semantics to CSS semantics w.r.t. Bidi functionality.

It is not possible in CSS to specify bidi-override without also setting direction, which alters the block progression direction (as indicated by the borders):

https://codepen.io/palemieux/pen/oNxrwZJ

In contrast, it is possible in TTML to specify bidiOverride without altering the block progression direction.

[skynavga]

Have you tried wrapping the content with explicit bidi controls, e.g., a LRE/RLE ... PDF pair to achieve the same result?

[palemieux]

Have you tried wrapping the content with explicit bidi controls, e.g., a LRE/RLE ... PDF pair to achieve the same result?

Is using the bidi controls strictly equivalent to setting bidiOverride on <p>? The discussion above seemed to imply otherwise?

[palemieux]

<p class="start-border">&#x202e;RLO with direction&#x202c;</p>

results in

(block progression is left to right)

[fantasai]

In response to @palemieux's #1211 (comment) and #1211 (comment):

No, specifying 'direction' on a paragraph and specifying 'direction' and 'unicode-bidi' on a span inside it are not equivalent.

UAX9 has some subtle differences in changing the paragraph embedding level vs wrapping the entire contents of the paragraph in an embedding. Off the top of my head, the way trailing white space on a line is handled is one difference.

In addition, in CSS at least, the alignment of a paragraph is keyed off its 'direction' property; the 'direction' property on a span has no effect on alignment. (And other flow-relative effects, such as mapping 'padding-inline-start' to its physical side, are also keyed off of the paragraph's 'direction', and not that of its descendants, obviously.)

---

Wrt @skynavga's algorithm at the end of #1211 (comment) :

I don't think this algorithm is correct, because the end of a UAX9 paragraph auto-closes all open embeddings. You need to split into paragraphs first, then add directional formatting characters to each such paragraph.

---

Wrt @palemieux's questions in #1211 (comment), I think these are the key questions that TTML needs to answer here.

---

Might be worth noting that 'unicode-bidi' values other than 'bidi-override' are all treated the same when specified on a block element such as a paragraph. The differences between normal/embed/isolate come into play on inline elements only, with normal causing changes in 'direction' to have no effect on the text, and embed vs. isolate having different effects on reordering at the boundaries of the inline element.

Lastly, I thought I'd link to a 45-minute video explaining the Unicode Bidi Algorithm, which might be helpful to anyone trying to follow this discussion who isn't familiar with UAX9. Caveat: it's from 2013, so before HTML adopted isolation for 'dir' attribute mapping.

[skynavga]

@palemieux regarding your comment #1211 (comment), you ask about "strict equivalence" here and elsewhere above; could you please define the context in which you are using this phrase and the purpose for which you wish this question answered? for example, this issue, and the ensuing discussion largely revolves around an implementation matter, in particular, how a particular implementation maps IMSC to HTML/CSS/JS for presenting IMSC content; TTML already gives formal guidance to implementers about equivalence regarding presentation semantics, specifically, in TTML2 2ed §11.3.1,

This section defines the semantics of region layout and presentation in terms of a standard processing model as follows:

[details removed]

Any implementation is permitted provided that the externally observable results are consistent with the results produced by this model.

The details that apply here that related to tts:unicodeBidi and tts:direction when applied to tt:p are defined by TTML2 2ed §10.2.48 and §10.2.12. Specifically, §10.2.12 states:

When applied to a p element, the computed value of this property explicitly establishes the paragraph level as specified by [UAX9], §4.3, Higher Level Protocol HL1.

We note here that (1) this does not specify that any semantics of tts:direction as apply to tt:p have any affect on the alignment (i.e., alignment in the inline progression dimension) of the borders, padding, etc., or content of the paragraph, and (2) the semantics that this does specify may be implemented in a variety of ways when it comes to obtaining

externally observable results [that] are consistent with the results produced by this model

One such way to produce such results are to do exactly what I have suggested, which is to wrap the paragraph's content with RLE/PDF. Now, I know that Elika has said there may be subtle differences with the UAX#9 output, and she is correct. This may produce bidi run levels that are shifted by 2. For example, if the original output (without the extra embed) were, say 0110, then this would produce an output of 2332, but that will not produce a visible difference at a paragraph level: evens and odds are preserved. So while it is not strictly equivalent UAX#9 output, it is equivalent in terms of directionality of the output runs.

Also, I left out the details above regarding subdividing a tt:p paragraph into UAX#9 paragraphs, i.e., sequences of text separated by PARAGRAPH SEPARATORs (or equivalent). Assuming this is taken into account, the above procedure does produce an equivalent result from the perspective of the TTML definition of equivalent observable results.

Having said the above, I do agree there is a specification issue which should be resolved at some point, though it need not be resolved in TTML2 2ed, and it is this: there are two scenarios for using tts:direction on tt:p, as follows.

1. standalone use of tts:direction to set the paragraph embed level for tt:p
2. use as a pair with tts:unicodeBidi in the same semantics as used with tt:span, where tts:unicodeBidi can take values including embed, override, isolate, etc.

When I was writing the text for §10.2.12 tts:direction, I explicitly had only the first of these two in mind. In fact, I encoded my understanding that only the first of these two scenarios applied when I wrote the lead paragraph and the two paragraphs that follow the table in §10.2.12:

Lead Paragraph

The tts:direction attribute is used to specify a style property that, depending on the context of use, determines (1) the bidirectional paragraph level, or (2) the directionality of a bidirectional embedding or override, about which see [UAX9].

Following Paragraphs (after table)

When applied to a p element, the computed value of this property explicitly establishes the paragraph level as specified by [UAX9], §4.3, Higher Level Protocol HL1.

When applied to a span element (or anonymous span), the computed value of this property, in combination with the computed value of the tts:unicodeBidi style property, determines the directionality of a bidirectional embedding or override as specified by [UAX9], §4.3, Higher Level Protocol HL3.

Reading this carefully, it is clear to me (at least), from the last of these paragraphs, that tts:direction is only used in combination with tts:unicodeBidi when tts:direction applies to a span element.

However, and here is the problem, §10.2.48 states that tts:unicodeBidi applies to span AND to p. So, I would propose that, at an appropriate point (which I deem to be after 2e), that p be removed from the applies to list of §10.2.48. I believe this is consistent with what I understand Elika is saying (that even in CSS, the non-normal unicode-bidi values are not supported).

[nigelmegitt]

In advance of our upcoming call I've been reviewing all of the material, and I will be asking the following question:

In #1211 (comment) @skynavga wrote:

1. Compute start and end edges - does tts:direction on p affect it, yes/no?

No. Nothing in the specification supports such a reading, and no such intention existed.

I want to question this statement, since if the answer is different then the main part of the issue disappears, since the TTML and CSS behaviours become coincident. I think there's good reason to interpret the specification differently:

1. XSL-FO defines text-align and clearly says that the start and end are relative to the inline-progression-direction,
2. XSL-FO says under direction:

The "writing-mode" property establishes both the block-progression-direction and the inline-progression-direction. The "direction" property only changes the inline-progression-direction and is used primarily for formatting objects that generate inline-areas that are not also reference areas. Use of the "direction" property for other formatting objects is deprecated in this specification.

Now it is also the case that TTML2 does not mention IPD explicitly in its definition of tts:direction. The only TTML2 style attribute that describes setting the inline progression direction is tts:writingMode.

At this stage I'm wondering if that is an accidental omission from the definition of tts:direction though, since the exception relative to both CSS and XSL is not called out, in either of the two places where it might be, i.e. the specification of the attribute itself or the informative derivation section.

[nigelmegitt]

Not sure quite how relevant it is - it may be a bug, but I also notice that the example rendering for the example fragment that supports tts:writingMode shows in the "tbrl" region that the line areas are laid out right to left, but the paragraph level appears to be left to right, within those line areas. That's confusing, since the special semantics of tts:direction clearly define that the computed value of tts:direction is the inline progression direction determined by tts:writingMode on the region given that no tts:direction is specified in the example. That being the case, I would expect the inherited value of tts:direction to be "rtl".

[fantasai]

One such way to produce such results are to do exactly what I have suggested, which is to wrap the paragraph's content with RLE/PDF. Now, I know that Elika has said there may be subtle differences with the UAX#9 output, and she is correct. This may produce bidi run levels that are shifted by 2. For example, if the original output (without the extra embed) were, say 0110, then this would produce an output of 2332, but that will not produce a visible difference at a paragraph level: evens and odds are preserved. So while it is not strictly equivalent UAX#9 output, it is equivalent in terms of directionality of the output runs.

This is incorrect, the case I described is a difference in rendering. I have no care about differences in the embedding level numbers, as you note that makes no practical difference in rendering.

[fantasai]

I believe this is consistent with what I understand Elika is saying (that even in CSS, the non-normal unicode-bidi values are not supported).

unicode-bidi: bidi-override does have an effect on block containers. Its the other values which are not distinguished.

[css-meeting-bot]

The Timed Text Working Group just discussed Interaction between tts:writingMode and tts:direction on paragraph element. w3c/ttml2#1211, and agreed to the following:

• SUMMARY: Agreed to raise follow-up issues on the application of unicodeBidi to p and on the application of direction to p

The full IRC log of that discussion

<nigel> Topic: Interaction between tts:writingMode and tts:direction on paragraph element. #1211
<nigel> github: https://github.com//issues/1211
<nigel> Nigel: [introduces topic] Any other points that are important here to get to a conclusion?
<nigel> Glenn: Difference of opinion between me and fantasai about getting to equivalence by wrapping
<nigel> .. text in bidi control characters. Given that we do not have a test case in terms of data
<nigel> .. and we don't have actual test suite or device to test such data against, we don't have
<nigel> .. anything to evaluate to determine whose opinion is correct.
<nigel> Nigel: I'm not seeing the application of the bidi algorithm as central to this issue.
<fantasai> scribenick: fantasai
<fantasai> palemieux: Here's a testcase. How should it be rendered?
<fantasai> glenn: this is a question on the semantics of 'direction' as it applies to P
<fantasai> glenn: I'd pointed out in my comments that there are two scenarios for use of direction in P
<fantasai> glenn: one is when it appears by itself, the other is when appearing in combination with unicode-bidi property
<fantasai> glenn: semantics of P only appear to apply when ...
<fantasai> glenn: only pertain to P unrelated to its combination with unicode-bidi
<fantasai> glenn: Originally we defined direction and unicode-bidi together, in CSS2.0
<fantasai> glenn: We copied from XSL:FO 1.0
<fantasai> glenn: And applied to span and P as well, but really didn't go into semantics of it in the case of SPAN or P
<fantasai> glenn: For some reason, we allowed to apply to SPAN and P but didn't talk about semantics very much
<fantasai> glenn: Now we have situation where we have unicode-bidi applying to both SPAN and P
<fantasai> glenn: and direction applying to both SPAN and P
<fantasai> glenn: But we subsequently redefined direction on P to apply only to the semantics of defining the paragraph level for UAX9 on P
<fantasai> glenn: and when we did that, we neglected to notice that we also had the case of it applying in combination with the unicode-bidi property on P
<nigel> q+
<fantasai> glenn: What we now have is a case where, if you put direction on P, and you also have unicode-bidi on P, what does that mean?
<fantasai> glenn: Does that mean the direction applies to the paragraph level? Or direction is supposed to be used in combination as for SPAN
<fantasai> glenn: definition of direction in TTML, pretty clear that direction use on P does not apply to unicode-bidi
<fantasai> glenn: so unicode-bidi property is just there, has no connection with P
<fantasai> glenn: so we do have a technical issue
<fantasai> glenn: Asking question of what this means, we have technical issue in this spec
<fantasai> glenn: Another problem fantasai points out, if we didn't have this technical problem, suppose hypothetically that this was equivalent to what we'd do with a SPAN, and you tried to map that to a P in CSS, now you have problem of CSS not defining what override is on P in CSS
<fantasai> For the record, CSS does define this
<fantasai> glenn: So that's a separate problem
<nigel> q?
<nigel> ack n
<fantasai> CSS spec - https://www.w3.org/TR/css-writing-modes-3/#text-direction
<fantasai> nigel: If we think about TTS direction on P, how it might affect the unicode-bidi algorithm
<fantasai> nigel: Glenn, you made a proposal that unicode-bidi should not apply to P in TTML, which resolves the issue that you just raised?
<fantasai> nigel: Another question was raised on the thread about the inline progression direction
<fantasai> nigel: XSL and CSS do take the 'direction' property to define the inline progression direction
<fantasai> nigel: And TTML doesn't say that it does. It only says that writing-mode sets the inline progression direction
<fantasai> nigel: But that looks like a weird omission, and is a source of difference that gave rise to a lot of the discussion on this issue
<fantasai> nigel: I wonder if it was an accidental omission
<fantasai> nigel: and direction should affect the inline progression direction as it does in XSL and CSS
<fantasai> nigel: If it did, if it were intended all along, then everything else would make sense
<fantasai> nigel: And all the other properties that depend on inline progression direction would fall into line and behave correctly
<fantasai> nigel: So that was my thought, that perhaps we ought to be modifying the text of tts:direction to say that it does in fact set the inline progression direction
<nigel> q?
<fantasai> glenn: It was not an accidental omission on my part. It was intentional that it did not apply
<fantasai> glenn: If you go back and read XSL:FO, I think you're missing some text where the context you quote
<fantasai> glenn: Says the language only applies when writing-mode applies to the object
<fantasai> glenn: So that quote that you make, where 'writing-mode' establishes ...
<fantasai> glenn: That is true for when 'writing-mode' applies to the FO object at hand
<fantasai> glenn: In this case the 'writing-mode' property does not apply to P, and only applies to regions in the case of TTML
<fantasai> glenn: The 'writing-mode' property does not apply to P
<fantasai> glenn: That's the problem with your argument
<fantasai> nigel: The text says the 'direction' property is used for FO objects that generate inline areas that are also not reference areas.
<fantasai> nigel: So talks about what direction does when applied to P
<atai> q+
<fantasai> nigel: You might be right about writing-mode, but we're talking about direction.
<nigel> ack at
<fantasai> glenn: P doesn't generate inline areas, it generates block areas
<fantasai> atai: It's difficult, the use of "inline progression direction". Not clear when it applies
<fantasai> atai: For example, inline progression direction sets directionality of edges, where start/end applies
<fantasai> atai: Also applies to unicode bidi algorithm
<fantasai> atai: It's clear in TTML that edges are only set by writing-mode
<fantasai> atai: and direction, inline-progression direction, and unicode bidi algorithm
<fantasai> atai: I think that's OK, direction isn't specified on region
<fantasai> atai: writing-mode is taken as the value, and inherits
<fantasai> atai: If direction is set on region, then the direction of region is taken into account
<fantasai> atai: But direction, as glenn said, only for inline objects
<fantasai> atai: but doesn't change how inline progression direction applies to regions
<fantasai> glenn: writing-mode establishes inline progression direction of the [?]
<fantasai> glenn: and [??] establishes inheritance
<fantasai> glenn: goes down to paragraph, so that paragraph inherits right value of 'direction'
<fantasai> glenn: that ultimately comes from region inhertance
<nigel> s/[??]/writingMode
<fantasai> glenn: So 'direction' affects what gets inherited, and can be overridden by direction on P
<fantasai> glenn: but as far as areas generated by P, those are block areas
<atai> q+
<fantasai> glenn: Anyway as for intention, I did not accidentally omit.
<nigel> q+
<fantasai> glenn: Might go back and reconsider, but it was intentional.
<fantasai> glenn: We noticed that there was language in XSL had the additional semantics of setting the base level of the paragraph for the bidi algorithm
<fantasai> glenn: We processed that issue, so there must be a record of us processing that issue
<fantasai> glenn: unicode-bidi property also applies to P, what does that mean, do we have a conflict now that we say that 'direction' can mean something by itself? Should we have left in the possibility of having both direction by itself and direction in conjunction with unicode-bidi?
<nigel> ack at
<fantasai> atai: I would like to bring this together with example that pal put up at the beginning
<fantasai> atai: What does direction mean when specified on a P
<fantasai> atai: would be good to get a common understanding of what this means
<nigel> q?
<nigel> ack nigel
<fantasai> nigel: If we do have a deliberate divergence from the definition of direction as it is defined in the specifications from which the TTML rendering model derives, we should call it out and explain why
<fantasai> nigel: It's unclear to me why we would have this divergence.
<fantasai> nigel: We should also be sure that this is the primary difference in what is defined in TTML vs CSS
<nigel> ack fantasai
<Zakim> fantasai, you wanted to answer that question
<nigel> scribe: nigel
<nigel> fantasai: No, the wrapping of content to the paragraph in an embedding is not the same as
<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=8562
<nigel> .. setting the embedding level on the paragraph as well. It's not just about the algo
<nigel> .. but also the outcome of it.
<nigel> .. test case above.
<nigel> .. Trailing whitespace is handled differently for example, it has special handling wrt the
<nigel> .. paragraph level. You cannot get the same effect.
<nigel> .. Second, there's a q what does unicodeBidi mean on a p.
<nigel> .. In CSS, if you set unicodeBidi on the paragraph level nothing happens if you set direction,
<nigel> .. unless you set unicode-bidi to override, in which case [???]
<nigel> .. It's not that there's no effect, but that the differences are relevant at the edges.
<nigel> .. Whether wrapped in isolate or embed makes no difference because the interesting thing
<nigel> .. is what happens outside that. So in CSS unicode-bidi does affect block level elements,
<nigel> .. so you could say it applies but in some cases has no effect.
<nigel> .. WRT the direction property and whether it affects IPD, this is the key issue.
<nigel> .. In CSS there's no concept of different direction vs IPD. We didn't think there was any reason
<nigel> .. for them to diverge so that isn't supported in CSS. If you want them to diverge you should
<nigel> .. have a use case. I can't think of any. It does seem to me that XSL does the same, so if you
<nigel> .. diverge then you'd be divergent from both XSL and CSS.
<nigel> .. Does XSL-FO define any elements that define a block area to which writingMode does not apply?
<nigel> .. That's a question I have that I don't know the answer to.
<fantasai> glenn: writing-mode does not apply to block elements in XSL
<nigel> Glenn: writing-mode does not generally apply to block elements in XSL.
<fantasai> glenn: it applie to higher-level constructs that construct page-level region type features
<fantasai> glenn: for organizing page layout, into which blocks are placed.
<fantasai> glenn: blocks tend to be children of higher-level constructs
<fantasai> glenn: Is there any way to set the paragraph-level in CSS independently of direction?
<nigel> fantasai: They're the same thing, the p level is set by direction
<fantasai> fantasai: paragraph-level base direction is set by 'direction'
<atai> q+
<fantasai> glenn: So the UAX9 direction and inline progression direction are bound together
<fantasai> fantasai: yes
<fantasai> fantasai: Question, what would it even mean to have them diverge, and why would you want to do it?
<fantasai> atai: As I read the HTML recommendation, I read that the use of markup to set writing direction instead of CSS where possible
<fantasai> atai: What glenn mentioned, explicit bidi control codes, should these be used at all?
<fantasai> fantasai: HTML dir attribute is defined to be mapped to CSS 'direction' property
<fantasai> fantasai: we strongly recommend to HTML authors to only use 'dir' attribute, not CSS
<fantasai> glenn: but authors might not follow that advice, could be mixed up
<fantasai> fantasai: yes, and the results are dictated by the Cascade
<fantasai> glenn: So you have to use both arbitrarily, and you have to map one of those techniques to the other in order to be consistent
<fantasai> glenn: What I've done in the past was to map all directional formatting characters to style or vice versa, to have a consistent data model to work with
<fantasai> fantasai: Yes, and CSS model requires that.
<fantasai> fantasai: CSS direction sets the paragraph embedding leve
<fantasai> fantasai: don't use the UAX9 heuristic unless opt-in via 'unicode-bidi: plaintext'
<fantasai> fantasai: but the rest of the CSS bidi controls are mapped to bidi control codes and passed to UAX9 algorithm
<nigel> q?
<fantasai> fantasai: if you're mixing markup and control codes in your source, this could get weird, but we do map it all into one system
<nigel> ack at
<fantasai> nigel: setting 'direction: rtl' and setting dir=rtl clearly behaves the same
<fantasai> nigel: Question implicitly stated earlier, but not properly asked
<fantasai> nigel: what's the use case for having a different value for inline progression direction from the paragraph embedding?
<fantasai> nigel: I don't think so far anyone has proposed such a use case.
<fantasai> nigel: So there doesn't seem to be one
<fantasai> nigel: If we were to make a change here, it would be a breaking change, because if there is someone who has authored documents...
<fantasai> nigel: that depend on this difference, that would present differently
<fantasai> nigel: But I suspect the state of implementation on this is not so solid anyway.
<fantasai> pal: Certainly in the case of TTML, no one I know of has run into this case.
<fantasai> pal: Now is the time to make a change if we want to make a change.
<fantasai> glenn: What kind of change do you have in mind?
<fantasai> pal: The only point I wanted to make is that now would be a good time to make a change if we're going to make a change.
<fantasai> pal: Just wanted to note that I don't think this is broadly deployed or broadly used
<fantasai> glenn: Don't know about ocntent out there
<fantasai> pal: Yeah, but based on folks we've worked with, sample content we've seen, either this is not deployed or least of anybody's worries.
<fantasai> glenn: Don't know how many ppl are trying to convert TTML to CSS
<nigel> scribe: nigel
<fantasai> pal: In my observation, I don't think we would be breaking people's content meaningfully if we made a change for interaction of direction and unicode-bidi on P
<nigel> ack f
<Zakim> fantasai, you wanted to make proposal
<nigel> fantasai: A straightforward thing to do would be to clarify the interaction between unicodeBidi
<nigel> .. and direction on p to match what CSS does.
<nigel> .. Another is to state that the direction property sets the ipd overriding whatever is set by
<nigel> .. writingMode, so it is a more specific control.
<nigel> .. Set both, direction wins, set one, then the one you set wins.
<nigel> .. Two ways to do it in terms of inheritance. Safest way probably would be to say that you
<nigel> .. do the mapping first and then inherit.
<nigel> .. The difference would be if you set both writingMode and direction on an ancestor then
<nigel> .. both would inherit through to the child. If the child sets a different direction it would
<nigel> .. override the parent. If the parent didn't set [xxx]
<nigel> .. There may be a choice if the child overrides...
<nigel> Glenn: [interrupts] there's already a detailed section about how to do the inheritance and
<nigel> .. compute the value.
<nigel> .. ONly applies to region, so we already have that.
<nigel> fantasai: OK, so you just need to specify that direction does set the ipd.
<nigel> Glenn: It is §10.2.12.1 by the way
<fantasai> nigel: That's two proposals. I think they both seem to match what CSS does, and I think also what XSL does. Takes away one of the divergences if I understood right
<fantasai> nigel: We mentioned the incompatibility that might produce, and lacking statistical data. Anecdotally, not going to trip anybody up with this.
<atai> q+
<nigel> ack at
<fantasai> atai: Third option, quite radical
<fantasai> atai: I understand how it was meant, but this is different issue
<fantasai> atai: But super difficult for a user to apply because not so many TTML experts
<fantasai> atai: Most people are coming from CSS, so difficult for them to understand
<fantasai> atai: Third option that was mentioned was to not only disallow unicode-bidi on P or say that it doesn't apply, but also say that 'direction' doesn't apply.
<fantasai> atai: I think from functionality we won't lose anything
<fantasai> atai: Having direction on P, instead use on inline elements.
<nigel> scribe: nigel
<nigel> fantasai: That is much more likely to break existing content because if people are using it
<nigel> .. on p then it will stop working. There are differences in rendering, not just theoretical ones,
<atai> q+
<nigel> .. so I don't think you'd get the right behaviour, so that would be a very bad option.
<fantasai> glenn: If we're going to allow direction on P to change inline progression direction on P, then need to do the same on DIV and BODY and potentially SPAN as well
<fantasai> pal: We don't have to
<fantasai> glenn: It would be asymmetric to do otherwise. All part of the inheritance hierarchy
<fantasai> glenn: Having it be special on P would be confusing / weird
<fantasai> nigel: But it doesn't apply currently.
<fantasai> glenn: That's true, they're just inheritable items
<fantasai> glenn: OK, so I guess because we have text-align and border/padding applying to P, that's why this might be relevant there.
<nigel> ack at
<fantasai> atai: You're absolutely right in terms of specification and compatibility, you're right
<fantasai> atai: But hard to get empirical data that, I hadn't seen people using unicode-bidi and direction at all
<fantasai> atai: And doubt they apply to P
<nigel> fantasai: unicodeBidi on p might be rare but I doubt direction woul dbe that rare
<fantasai> atai: But seeing how long we discuss on this thread, even if people use it, what is the intent actually?
<fantasai> atai: Specification group, after publishing it, coming to agreement on how this applies, how are the users going to udderstand
<nigel> fantasai: Users have a much easier job because all they're doing is saying if the p is rtl or ltr primarily
<nigel> .. and set writingMOde or direction appropriately.
<nigel> .. They're not thinking about all the complex implications, or thinking about how it works.
<nigel> .. It's the implementor's job to figure out how it works. THere are countless hours
<nigel> .. spent figuring out how the unicode bidi algo works, mapping to HTML etc.
<nigel> .. Users just have to label the content appropriately.
<fantasai> nigel: Feels as though on this call, seems we've ended up in place of understanding what the spec says now and what the divergence is from CSS, and proposal for two actions to take to address it and clarify
<fantasai> nigel: From those points, has anybody been holding back any questions?
<fantasai> glenn: I haven't seen the text of the proposals, so haven't reviewed the text of the proposals.
<fantasai> glenn: I would like to withhold my final comment
<fantasai> nigel: of course, we can all review things
<fantasai> glenn: I would like to talk about the strategy and timing
<fantasai> nigel: On the substance of the issue, though, are there unresolved questions or comments?
<fantasai> nigel: I'm only aware of one, mine, possibly handle later
<fantasai> nigel: In the section on writing-mode in the spec, there's an example fragment
<fantasai> nigel: that's a region that sets a region to tbrl, but the text appears to have an LTR direction
<fantasai> glenn: RL in this case means right-to-left lines. Block progression mode is right to left. Top to bottom inline progression mode
<fantasai> nigel: So writing-mode does apparently affect the inheritance of 'direction', we saw that earlier in the section on 'directin'.
<fantasai> glenn: Mapping from each value of 'writing-mode' into the corresponding direction isn't specified.
<fantasai> nigel: You're saying that in tbrl ...
<fantasai> glenn: RL there is not the same as RTL in direction
<fantasai> glenn: RL means the block direction
<fantasai> nigel: That mapping isn't defined, not listed anyonere.
<fantasai> nigel: Means lines are being laid out on their side. It's a vertical mode
<fantasai> nigel: If I'm reading this and trying to understand what is the value of 'direction' I'm trying to derive from this, hard to tell
<fantasai> nigel: tbrl doesn't mean rtl, how do I know that?
<fantasai> glenn: It has nothing to do with bidi
<fantasai> nigel: So inline progression direction determined, according to specifics
<fantasai> nigel How is it mapped?
<fantasai> glenn: top-to-bottom would be LTR basically
<fantasai> glenn: It would depend on the rotation of the text
<fantasai> glenn: If the text were zero-degress oriented, clockwise
<fantasai> glenn: Depends on the orientation. If the orientation is upright, then you can't tell.
<fantasai> glenn: If the orientation is 90deg, then it would be LTR from bidi perspective.
<fantasai> glenn: If orientation is 270deg then it would be RTL
<fantasai> nigel: We have mixed, sideways, and upright
<fantasai> glenn: You'll have to go back to XSL:FO defnitions
<nigel> fantasai: writingMode rl => rtl and everything else to ltr probably
<nigel> .. tbrl and tblr probably should not set direction at all, just allow it to inherit
<nigel> Glenn: You might find some example images inside the XSL-FO spec. I recall seeing some there.
<nigel> .. You would have to know the orientation angle to accurately interpret that.
<nigel> .. Elika's heuristic is probably a good one.
<nigel> fantasai: The orientation mixed/upright/sideways, in CSS, if orientation is upright, which
<nigel> .. forces even rtl letters to be upright, then direction is forced to ltr regardless of value
<nigel> .. so when you run bidi everything is laid out top to bottom. You don't have to worry
<nigel> .. about that in TTML - the CSS definition will take care of that.
<nigel> Glenn: That makes sense, it wouldn't make sense in say Arabic, unless you're doing something
<nigel> .. where the letters aren't connected anyway.
<nigel> fantasai: Yes, if you force upright in Arabic then you go top to bottom.
<fantasai> nigel: So seems like two proposals here, not clearly written down, but clear to me what those proposals are
<fantasai> nigel: Glenn, you wanted to mention strategy. Which version of the spec we should make changes to?
<fantasai> glenn: My suggestion would be to give fair warning that a change is coming in 2nd Edition
<fantasai> glenn: Add some informative material, but not actually make a substantive change here.
<fantasai> glenn: I think it's too late to make this kind of change in 2nd Edition. That's my opiniont.
<fantasai> pal: I would even go one step back and say, the first step is to actually capture what the proposed solution is as an issue.
<fantasai> pal: Let's capture what the change is, so implementers can experiment with it
<fantasai> pal: And when we feel it's ready to merge into the spec we can see where we are.
<fantasai> glenn: Agree this issue is getting too wild.
<fantasai> pal: Maybe someone can make a proposal as a PR against this issue. Lable it WIP/Do not merge. Take the time to make sure it works
<fantasai> pal: We can merge it when we're ready
<fantasai> glenn: Against this issue ?
<fantasai> pal: My goal is to find a solution that works
<fantasai> glenn: This issue has many sub-issues.
<fantasai> pal: This edition of spec, but brand new issues
<nigel> fantasai: Two issues, one for ipd from direction, the other for unicodeBidi on p
<fantasai> nigel: Sounds sensible.
<fantasai> nigel: Already discussed outcome of this meeting. once we've captured clearly like this, let's run it by CSS and i18n
<fantasai> nigel: If we can get time with them in the next couple weeks, can get the issues logged. Seems feasible.
<fantasai> nigel: Another question of what to do in specific versions. Let's have an aside to think about impact of change.
<fantasai> nigel: Impact of change to users if we make a change directly instead of signalling.
<fantasai> nigel: Also an impact if we don't make a change.
<fantasai> nigel: Also a question of process, if we make a normative change to TTML now
<pal> q+
<fantasai> nigel: Might need to go back to CR. Don't think we need to go back to WD.
<fantasai> nigel: That would incurr minimum period to move to PR. But that said, we're not ready for PR yet anyway
<fantasai> pal: Suggest not talking about process today, instead let's craft the issues.
<fantasai> pal: Since we have all the experts on the line
<fantasai> pal: From my perspective, I'd love to be able to implement those solutions ASAP
<nigel> ack pal
<fantasai> pal: Make sure it can be implemented, and get user feedback asap
<fantasai> glenn: I have to run off. I think I've got enough information that I can start moving ahead with crafting a new issue or issues.
<fantasai> glenn: I'll consult with fantasai and pal if that's OK
<fantasai> pal: Yeah, go ahead!
<fantasai> pal: Best to do next few days, so we can review through TPAC joint meetings
<fantasai> nigel: Next week would be too long
<fantasai> fantasai: I can help by filing the issues, and then can figure out the wording later
<fantasai> nigel: Main thing is capturing it
<fantasai> fantasai: We could file the issues at a high level, and you can work on the wording as a follow-up. Does that work?
<nigel> fantasai: Propose to file the issue, then you can take the lead on the editing. Work for you Glenn?
<fantasai> glenn: OK
<fantasai> nigel: OK, that's the plan.
<nigel> fantasai: happy to stay on and draft issues
<nigel> .. paragraph one and unicode is easy
<nigel> pal: do it now?
<fantasai> https://www.w3.org/TR/css-writing-modes-3/#text-direction
<nigel> Nigel: Raised #1212
<atsushi> #1212 -> https://github.com//issues/1212
<nigel> .. And #1213
<nigel> #1213 -> https://github.com//issues/1213
<nigel> SUMMARY: Agreed to raise follow-up issues on the application of unicodeBidi to p and on the application of direction to p