Remove applicability of tts:direction on <p>

[palemieux]

Closes #1211
Closes #1213
Closes #1212

The paragraph embedding level is determined by the ipd, instead of being determined by tts:direction as applied to p. This is compatible with CSS since, in CSS, direction sets the paragraph embedding level and the combination of direction and writing-mode maps to tts:writingMode.

The effect of tts:unicodeBidi on p is clarified to match CSS.

[nigelmegitt]

Notes to consider (partly for myself, but sharing them in case others have views):

• Should we change the semantic derivation for tts:direction to be CSS 3 Writing Modes?
• Improve interoperability of tts:direction on tt:p with CSS3 implementations. #1213 doesn't say to remove the applicability of tts:direction to p, but that's what this PR does.
• Improve interoperability of tts:direction on tt:p with CSS3 implementations. #1213 says to make tts:direction on p set the inline progression direction in addition to the paragraph embedding level, but this PR does not do that.
• Remove application of tts:unicodeBidi to tt:p element. #1212 says to remove the applicability of tts:unicodeBidi from p, but this PR does not do that.

At the moment, it looks to me, unless I've misunderstood, that the PR does not match the requested changes from the issues it is intended to close. I look forward to discussing.

[palemieux]

At the moment, it looks to me, unless I've misunderstood, that the PR does not match the requested changes from the issues it is intended to close. I look forward to discussing.

Yes, the PR attempts to find a middle ground to address the concerns with changing the semantics of tts:direction on p to influence the IPD.

[css-meeting-bot]

The Timed Text Working Group just discussed Remove applicability of tts:direction on <p> w3c/ttml2#1214, and agreed to the following:

• SUMMARY: Continue reviewing

The full IRC log of that discussion

<nigel> Topic: Remove applicability of tts:direction on <p> #1214
<nigel> github: https://github.com//pull/1214
<nigel> Pierre: My summary: long discussion on #1211. Boils down to what does tts:direction
<nigel> .. actually do when applied to p. 4 options available:
<nigel> .. 1. Keep things exactly as is by having tts:direction on p have no effect on the inline progression direction.
<nigel> .. This is probably what TTML and XSL-FO have in mind but is incompatible with CSS3.
<nigel> .. 2. Make things consistent with current CSS by having tts:direction on p override the inline
<nigel> .. progression direction set by the writing mode.
<nigel> .. This is inconsistent with existing TTML and XSL-FO.
<nigel> .. 3. Make tts:direction not applicable to p and instead set the paragraph embedding levels differently.
<nigel> .. 4. Keep things as is but note that the result of applying tts:direction on p is implementation-dependent.
<nigel> .. The PR I propose is a compromise, option 3 here.
<nigel> .. It makes tts:direction not applicable on p, removes the opportunity for inconsistency.
<nigel> .. Instead the paragraph embedded level is set from the computed value of the
<nigel> .. writingMode on region, so it is always set to the inline progression direction as determined on region.
<nigel> .. It's consistent with the spirit of TTML, and compatible with modern CSS, and if we ever
<nigel> .. change our mind we can make tts:direction applicable again and maybe then it will be
<nigel> .. more obvious what to do.
<nigel> .. As an aside, we have to decide what to do with unicodeBidi on p, which should be easier
<nigel> .. to deal with.
<atai> q+
<nigel> ack at
<nigel> Andreas: I have minor comments on the pull request but in general I fully agree with the
<nigel> .. intent, for the reasons Pierre mentioned.
<nigel> q+
<nigel> ack nige
<nigel> Nigel: What's the impact in terms of potentially breaking existing documents?
<nigel> Pierre: It's really hard to tell. I've not seen many if any right to left IMSC documents in the wild.
<atai> q+
<nigel> .. The few I have seen I think just set the writingMode and that's it, without any direction.
<nigel> .. I don't know, in terms of hard numbers.
<nigel> .. If we're going to settle on something now is a good time.
<nigel> Nigel: Not quite what I meant - rather, if there were a document with direction on p, and
<nigel> .. we made this change, what would be the impact?
<nigel> Pierre: If the author set direction to explicitly set the paragraph embedding level explicitly,
<nigel> .. presumably that would be consistent with the writingMode, because it would be unusual
<nigel> .. to set the two unequal, so there would be no change.
<nigel> .. If an author had used tts:direction on p to override the inline progression direction set
<nigel> .. by writingMode that would break those documents. Why would someone do that? Maybe
<nigel> .. because they think they're in CSS? This approach would break those documents, possibly.
<nigel> ack a
<nigel> Andreas: If you specify tts:direction on p or reference a style through some inheritance then
<nigel> .. it is actually specified for p. It is not an error - you can do it even if there is no effect.
<nigel> .. The question about the change breaking, my interpretation is that you would set direction
<nigel> .. on p and there is a deterministic behaviour expected for the rendering. From the long
<nigel> .. long thread we had on that, where all the experts were discussing and could not really
<nigel> .. get a grip on it and agree, it seems to be agreed that there's no deterministic behaviour
<nigel> .. so therefore it doesn't break anything. On the contrary, if you do that, it might not even
<nigel> .. break an existing application. I would argue that if an application would render it the
<nigel> .. way CSS3 does it, it would maybe be okay, but at least not an error.
<nigel> .. If you now fix and make normative a deterministic behaviour then it is very clear that
<nigel> .. some implementation is no longer conformant.
<nigel> Nigel: Thanks, that's a good point, definitely food for thought.
<nigel> .. I think what you're saying is that this change removes from reachability some features
<nigel> .. of CSS, in that you couldn't get a mapping from a TTML2 document by a processor
<cyril> q+
<nigel> .. conformant to this PR, which would end up setting the direction property on a p element.
<nigel> .. If you're mapping from TTML to HTML + CSS, say.
<nigel> .. Is that fair?
<nigel> Pierre: exactly. The only place where you would set the direction property would be the
<nigel> .. equivalent of the region TTML element, which is fine because that's where the inline
<nigel> .. progression direction is set.
<nigel> ack cy
<nigel> Cyril: When Pierre said he hadn't seen Arabic documents in the wild I was wondering what
<nigel> .. we do at Netflix. We have 100,000s Arabic documents. I picked one completely at random
<nigel> .. and it uses direction on p.
<nigel> .. I will paste the example.
<nigel> .. The document I have has no writingMode on the region at all.
<cyril> <p xml:id="p1" begin="00:02:15:02" end="00:02:16:16"><span tts:unicodeBidi="embed" tts:direction="rtl">اجعل نوم أخيك...</span></p>
<nigel> Andreas: The direction is on span not p
<nigel> Cyril: Sorry, I need to wake up!
<nigel> Andreas: Exactly how it should be used.
<nigel> Cyril: I will try to see if we ever use direction on a p
<nigel> Pierre: In general that's the question.
<nigel> Nigel: It seems like Netflix is the best placed to give us real world data.
<atai> q+
<nigel> Cyril: I'm looking. I think the difficulty is checking various vendors. I suspect that if all
<nigel> .. vendors use the same tool, given there's a restricted set of production tools, once we have
<nigel> .. looked at the output of all those tools, if none of them use direction on p then we're
<nigel> .. probably in good shape.
<cyril> <p style="style.default" region="region.after.center" begin="00:00:12:00" end="00:00:14:07"><span tts:direction="rtl">مسلسلات NETFLIX الأصلية</span></p>
<nigel> Pierre: If they use it on a p and it is consistent with writingMode then it's not terrible.
<nigel> Cyril: Another example above, again nothing on the p or region
<nigel> .. I will run some queries before expressing an opinion on the change.
<nigel> ack at
<nigel> Andreas: It's also important to see what would happen if you removed it if you do find it.
<nigel> .. It should be an interoperable behaviour, and at least it should be tested.
<nigel> Pierre: I will work on implementing Andreas's suggestions - they don't change really the
<nigel> .. fundamental proposal.
<atai> q+
<nigel> .. I do want to understand why the group concluded that unicodeBidi is not applicable on p
<nigel> .. when CSS does say some values are applicable to p. I'm happy either way. It would be
<nigel> .. good to get confirmation there.
<nigel> ack at
<nigel> Andreas: I've seen in your comments you asked for a reference. I couldn't find the discussion
<nigel> .. part but in one of Glenn's latest comment he said he considered removing the application
<nigel> .. of unicodeBidi from p in a later version and that's my recollection from the discussion as
<nigel> .. well, and there's issue #1212 that says to do this.
<nigel> Pierre: If you go to the latest CSS drafts, some values of unicode-bidi that do have an impact
<nigel> .. on p, including embed. We should point to some discussion or assessment in the PR I think.
<nigel> Andreas: There is a part of the minutes where Elika explained what they do if it is applied to p.
<nigel> Pierre: yes, it's in the CSS spec. I think that's less urgent.
<nigel> .. My goal is to close this by end of year.
<nigel> Nigel: Good discussion on this given the PR is only 11 hours old so already a massive step
<nigel> .. forward, let's keep reviewing.
<nigel> SUMMARY: Continue reviewing

[cconcolato]

Following our discussion I found one example in our catalog that uses dir on p:

<p begin="10844167t" end="29195834t" region="bottom" tts:direction="rtl" tts:unicodeBidi="embed" xml:id="ID_57d7c57f-ef91-42fd-8f32-0d1f237b5131">
  <span style="span">- תוכן מקורי של NETFLIX -</span>
</p>

the region is defined as

<region tts:backgroundColor="transparent" tts:displayAlign="after" tts:extent="80.000% 80.000%" tts:origin="10.000% 10.000%" tts:textAlign="center" xml:id="bottom"/>

writing-mode is not used at all in the document

[palemieux]

<p begin="10844167t" end="29195834t" region="bottom" tts:direction="rtl" tts:unicodeBidi="embed" xml:id="ID_57d7c57f-ef91-42fd-8f32-0d1f237b5131">

@cconcolato What is the expected rendering?

[skynavga]

This language is semantically inconsistent with §10.2.12.1.

[palemieux]

What is the semantic inconsistency?

[skynavga]

It is inappropriate to deprecate functionality that has been deployed since TTML1 1st edition without providing a mechanism for an author to explicitly declare which behavior is desired (either the pre-existing behavior or the newly proposed, non-backwards compatible behavior). In other words, this change should not be treated as a candidate for deprecation.

[skynavga]

See above comment about deprecation.

[skynavga]

Re: #1214 (comment), please note that the abbreviation ipd does not mean inline progression direction in TTML, it means inline progression dimension; therefore, to avoid confusion, it is best to spell out inline progression direction.

[skynavga]

@cconcolato Re: #1214 (comment), I would expect the rendering to be such that the region is left-right, top-to-bottom, containing a horizontally center aligned paragraph that has its content effectively wrapped in a RLE/PDF Unicode Bidirectional Controls pair, which content consists of the text

- תוכן מקורי של NETFLIX -

The Bidi reordered text should appear as follows, and translates as "Original Content of NETFLIX".

- NETFLIX תוכן מקורי של -

[css-meeting-bot]

The Timed Text Working Group just discussed remove applicability of direction on p, and agreed to the following:

• SUMMARY: Pull Request is closed without merging due to lack of consensus

The full IRC log of that discussion

<cyril> Topic: remove applicability of direction on p
<cyril> github: https://github.com//pull/1214
<cyril> nigel: we have comments from Glenn
<cyril> ... Pierre tried to address Andreas' comments
<cyril> ... Andreas approved them
<cyril> ... Glenn says there is some semantic inconsistency
<cyril> ... we need to workout what that means
<cyril> pal: the computed value of tts:direction on a region can come from 2 different places
<cyril> ... implicitly from tts:writingmode or explicitely if you specify it or initial value
<cyril> ... I don't see why Glenn is unhappy
<cyril> nigel: it's not obvious is it?
<cyril> nigel: we need to ask glenn
<glenn_> mainly, i
<glenn_> mainly, i'm not happy with using a dull axe to cut out tts:direction semantics
<cyril> q+
<glenn_> we went to a lot of trouble to define out tts:writingMode maps to tts:direction which maps to paragraph embedding level in UAX#9; there is no need to remove those semantics
<nigel> scribe: nigel
<nigel> cyril: Since last time I did some research in our catalogue.
<nigel> .. I found 2 things.
<nigel> .. 1. I found more example of tts:direction being used on p, and not only from internal Netflix tools
<nigel> .. but at least 2 external vendors who produce such content.
<nigel> .. The content I found has tts:direction on p, no writingMode on region, but textAlign on p, most usually "center".
<nigel> .. I need to search for other cases where textAlign is not used.
<nigel> .. I am really worried that if we make this change to indicate that direction does not apply on p, there could be an impact on these
<nigel> .. Netflix external vendors.
<atai> q+
<nigel> s/The content/2. The content
<cyril> ack cyril
<cyril> scribe: cyril
<glenn_> I am also unhappy with (read cannot and will not accept) deprecating.
<cyril> atai: coming back to the rendering question
<cyril> ... what are the expectation of vendors when putting this value on p
<cyril> ... what interpretation is done by the renderers
<cyril> ... what should be the rendering
<glenn> thinks nobody is reading IRC except me
<cyril> ... I struggle to see how the situation could be worse if we remove applicability on p
<nigel> q+
<nigel> ack at
<glenn> cannot accept deprecation approach
<cyril> ... because it seems implementation dependent
<nigel> q?
<nigel> ack n
<cyril> nigel: there is a missing data
<cyril> ... for the content that Cyril has found, that sets direction
<cyril> ... presumably it is setting direction to rtl
<glenn> what is the missing data?
<glenn> you do realize that the bidi algorithm uses the character directionality?
<cyril> ... is there a common expecting rendering behavior that you would be expected and that would change if direction applicability is removed
<glenn> ah, someone is reading....
<glenn> sorry, i'm not on audio
<cyril> nigel: specifically, around what is implemented now vs any hypothetical implementation
<cyril> pal: a very general observation is that implementations prior to 2017 or 2018 of TTML, perhaps with the exception of ttv and ttpe, were terrible
<cyril> ... In my experience, produced documents that today would be deemed not conformant
<cyril> cyril: Netflix has received plenty of documents prior to 2017 that were fine
<glenn> @pal have you used all implementations? i haven't
<nigel> q+
<cyril> pal: but what does direction mean then in these documents
<cyril> cyril: maybe that its equivalent to writing mode
<nigel> q?
<cyril> nigel: there is a stated meaning of direction p
<cyril> ... I don't think anybody doubts that it sets the paragraph embedding level
<cyril> ... if the result of this change meant that it no longer did that, then a bunch of text already out there, if you rendered it with a now conformant implementation, would render in the incorrect order
<cyril> ... that wouldn't be right
<nigel> ack n
<atai> q+
<cyril> pal: that's not accurate
<nigel> q+ pal
<nigel> ack at
<cyril> atai: going back to what Cyril said, that it was clear what directionality on p, I can guess that they wanted to indicate that the content in the p had the direction indicate in the tts:direction attribute
<cyril> ... especially to override the left to right direction because they did not specify writing mode
<cyril> ... if we follow the text in TTML2 as of now, i.e. setting the embedding level, this has an effect on arabic and hebrew
<cyril> ... because the neutral and weak characters would use it
<cyril> ... the issue we are facing is how it is defined in TTML is that it separates the directionality from the inline progression direction
<cyril> ... CSS3 does both at the same time while TTML2 does not
<glenn_> q+
<cyril> ... the problem is that most authors would expect that it behaves like CSS
<cyril> ... either way there will be problems
<nigel> q+ to say that #1213 is the issue that implements Andreas's point
<nigel> ack pal
<cyril> ... and not the expected rendering from the authors
<cyril> pal: as an example where this is not clear is the case where you have arabic (rtl) but writing mode is set (ltr) and textAlign is set to center
<atai> q+
<cyril> ... in that particular tts:direction will have no impact
<cyril> ... if it's pure arabic with no latin
<cyril> ... so that's the case where somebody might set tts:direction thinking it would do something but it does nothing
<glenn_> not true
<nigel> ack glenn_
<cyril> ... because some think it may set the alignment but they use text align
<nigel> nigel: Glenn please go ahead via IRC
<glenn_> I would like to point out (yet agaiin)
<glenn_> that tts:direction is used in two context with respect to tt:p
<glenn_> and one context with respect to tt:span
<nigel> q?
<glenn_> it is used with tts:unicodeBidi as a parameter
<cyril> nigel: I think that's well understood in the conversation
<glenn_> i don't think so
<glenn_> with tt:p it has two uses
<glenn_> we need to know which context applies
<glenn_> if we are talking about the use where it appears by itself
<glenn_> then tts:direction only means set the default paragraph embedding level
<glenn_> and that does have an impact
<glenn_> it means something and has a visual interpretation w.r.t. neutral characters
<glenn_> so I don't know why pal is saying it has no impact
<cyril> nigel: in Netflix cases, is tts:direction applying with unicodeBidi?
<cyril> cyril: no
<glenn_> it has nothing to do with textAlign
<cyril> cyril: there is no unicodeBidi in my example
<nigel> q?
<nigel> ack nigel
<Zakim> nigel, you wanted to say that #1213 is the issue that implements Andreas's point
<glenn_> I don't have the example in front of me
<glenn_> I think the examplle I looked at DID have unicodeBidi
<cyril> nigel: I wanted to make a point that the main things was that Andreas made a good point about the direction and CSS compatibility
<cyril> ... and that's precisely issue #1213 and that is not implemented
<glenn_> it had tts:unicodeBidi="embed"
<cyril> ... sorry, this is confusing
<cyril> ... in this PR, I don't think it does that
<cyril> pal: the PR is compatible with CSS
<cyril> ... because the PR proposes that the paragraph embedding level be set by the inline progression direction computed on the region
<cyril> ... which in CSS would be set by direction
<nigel> q?
<cyril> nigel: I will close the queue on this to move on in the agenda
<nigel> ack atai
<cyril> atai: I agree with Pierre that the PR solves the conflict with CSS because it avoids the situation where TTML acts differently from CSS
<cyril> ... but I also need to agree with Glenn that setting tts:direction to RTL and have centered arabic text as content in that p, will render different from the case where you have not set tts:direction on the p
<glenn_> that is precisely the semantic inconsistency I point out in my comments
<glenn_> tts:writingMode does not apply to tt:p
<cyril> ... there have been some examples in the long long thread
<cyril> ... where I mixed some latin text with weak characters and numbers, and this will be rendered differently
<cyril> ... I'm not sure if we discussed the option that some parts of the rendering could be implementation dependent
<cyril> ... I think that reflects the reality at the moment
<cyril> ... at least regarding the setting the edges
<glenn_> tts:writingMode applys to tt:region which has special semantics that flow to tts:direction which inherit down to tt:p which apply to paragraph embedding level WHICH NEEDS TO STAY AS DEFINED
<cyril> ... saying that it's not clear in the spec and implementation dependent
<cyril> pal: I will withdraw my PR
<glenn_> I support withdrawal of the PR, thank you pal
<cyril> SUMMARY: Pull Request is closed without merging due to lack of consensus