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