Open palemieux opened 4 years ago
this is a revisionist view of history
I am not making a statement on the history of CSS, only how I think CSS is implemented today. If an essential feature was lost in the crafting of CSS Writing Modes, then we should report it. This is why I recommend we identify essential use cases that are not supported by CSS in its current form.
Firstly, I have not seen evidence that one cannot map* TTML2 semantics to CSS semantics w.r.t. Bidi functionality. Secondly, even if one could identify unmappable functionality (and that has not occurred yet), that is not sufficient grounds to modify the alter the existing TTML2 functionality IMO.
*In the prior thread, much discussion has revolved around equivalence, and yet the underlying requirement has not been articulated. I don't believe semantic equivalence is what is being asked for here, but only equivalent visual results (and that to only a degree). That question has not been put to this thread. When I have been discussing equivalence above, I have been referring to the exact results of the UAX#9 algorithm, including bidi level assignments. But, if you are familiar with UAX#9, you will know that different bidi level assignments can produce the same visual results (w.r.t. bidi ordering).
@skynavga my understanding of the potential change being proposed to TTML, if any, is to remove the p
element from the applies-to list of tts:direction
; the argument is that it would still apply to anonymous spans via the span
entry in that list.
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
?
From your previous comments, it seems that tts:direction
on p
is not expected to affect the interpretation of the start
and end
keywords, though that is another change that could be introduced, as per @palemieux 's https://github.com/w3c/ttml2/issues/1211#issuecomment-682074562.
@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.
The Timed Text Working Group just discussed Interaction between tts:writingMode and tts:direction on paragraph element. w3c/ttml2#1211
.
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.
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.
Have you tried wrapping the content with explicit bidi controls, e.g., a LRE/RLE ... PDF pair to achieve the same result?
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?
<p class="start-border">‮RLO with direction‬</p>
results in
(block progression is left to right)
In response to @palemieux's https://github.com/w3c/ttml2/issues/1211#issuecomment-676466382 and https://github.com/w3c/ttml2/issues/1211#issuecomment-677713574:
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 https://github.com/w3c/ttml2/issues/1211#issuecomment-681315212 :
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 https://github.com/w3c/ttml2/issues/1211#issuecomment-682074562, 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.
@palemieux regarding your comment https://github.com/w3c/ttml2/issues/1211#issuecomment-702448590, 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.
tts:direction
to set the paragraph embed level for tt:p
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 thetts: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).
In advance of our upcoming call I've been reviewing all of the material, and I will be asking the following question:
In https://github.com/w3c/ttml2/issues/1211#issuecomment-677958813 @skynavga wrote:
- 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:
text-align
and clearly says that the start and end are relative to the inline-progression-direction, 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.
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"
.
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.
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.
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
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
andtts:writingMode
should conflict on<p>
? In other words, does specifyingtts:direction="ltr"
ever make sense iftts:writingDirection="rl
? CSS does not allow this inconsistency.what does
tts:direction
mean when the IPD is vertical? UAX #9, clause 6.2 implies thattts: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 bytts:writingDirection
. In the case where the block progression direction is horizontal,tts:direction="ltr"
specifies a top-to-bottom inline progression direction whereastts:direction="rtl"
specifies a bottom-to-top inline progression direction.