[css-text-4] [text-autospace] Spacing across element boundaries for BiDi content

[vitorroriz]

Spec says:

At element boundaries, the amount of extra spacing introduced between characters is determined by and rendered within the innermost element that contains the boundary.

We need to calculate such spacing before line-breaking as the extra spaces between relevant elements affect the available space for composing a line. At this point visual re-ordering hasn't occurred and ordering is considered logical (we process text in the order it is stored).

After layout, for actually displaying text, if content requires visual re-ordering due to BiDi content, what should the engine do regarding the extra spaces?

1. We could re-compute spacing based on the potential new visual order, but this won't match the spacing computed during layout, generating a mismatch between "layout" and "display".
2. We can try to re-use the spacing computed in layout, but that is still "wrong" as we might be adding spacing between characters that are no longer adjacent and missing spacing between characters that are now adjacent.

[vitorroriz]

cc: @kojiishi @fantasai

[fantasai]

An example of this would be something like

一些中国字<bdi dir=rtl>HEBREW$SYMBOL$</bdi>中国字.

In visual order it would be

一些中国字$SYMBOL$WERBEH中国字.

If we insert the spaces before reordering, we get

一些中国字 $SYMBOL$WERBEH中国字.

instead of

一些中国字$SYMBOL$WERBEH 中国字.

I think visual-order separation is the right answer, but I'm not sure how important it is to get it right: it'll feel a bit weird either way since we're not setting apart the whole phrase, only half of it. (The autospace rules currently let symbols attach to both CJK and non-CJK contexts, but in this example it's clearly associated with the non-CJK context.) Curious if i18n has realistic examples.

I think the main things we need to ensure are:

• If both sides of a directional run require autospace, we autospace them appropriately.
• We never double-autospace either side.

[css-meeting-bot]

The CSS Working Group just discussed [css-text-4] [text-autospace] Spacing across element boundaries for BiDi content, and agreed to the following:

• RESOLVED: autospacing happens *after* bidi-reordering, and we'll add a complex example to the spec

The full IRC log of that discussion

<TabAtkins> fantasai: so text-autospace inserts spaces between "changes" in a script
<TabAtkins> fantasai: if you ahve chinese with a little englihs, there should be some gap around the english otherwise it feels cramped
<TabAtkins> fantasai: q is what to do with bidi text
<TabAtkins> fantasai: we dont' insert space between chinese text and a *symbol*, only between chinese text and a letter
<TabAtkins> fantasai: so if you had a stretch of rtl text, like hebrew that ends with a symbol
<TabAtkins> fantasai: and you give it a direction so it all flips
<TabAtkins> fantasai: so symbol is on the left, hebrew letters on the right
<TabAtkins> fantasai: chinese text before and after
<TabAtkins> fantasai: if you insert space before reordering, you'll put it on the left side, which ends up between the chinese text and the symbol, while the hebrew and chinese dont' get a space
<TabAtkins> fantasai: so correct answer is to manage the sapce in visual order, after bidi reordering
<TabAtkins> fantasai: this is challenging, it interacts with linebreaking in awkward ways. hard to get perfectly right without maybe some backtracking
<TabAtkins> fantasai: so i think th e correct answer is visual spacing
<TabAtkins> fantasai: for practicual purposes, might tolerate getting it wrong in some complex cases
<TabAtkins> florian: do we need to spec the allowance for getting it wrong?
<TabAtkins> florian: or jsut spec the right thing and expect people to get it wrong sometimes, but they should still try?
<TabAtkins> fantasai: i'm not sure
<TabAtkins> fantasai: i think it's important to maek sure we get right - if both sides require spacing, it's done correctly, never get double space on one side
<TabAtkins> fantasai: that's minimum bar
<TabAtkins> astearns: I think we should specify what we want to see, without allowance, and only do that "getting it wrong is allowed" part if we have to
<TabAtkins> fantasai: i think that's reasonable.
<TabAtkins> fantasai: if authors are running into problems with certain cases, they can complain, and then we'll know those cases matter.
<TabAtkins> astearns: so proposed resolution is we specify that autospacing is done after bidi reordering
<TabAtkins> astearns: and you should never double auto-space any side
<TabAtkins> fantasai: yeah, that's implied
<TabAtkins> florian: do we want to add a note about it being hard?
<fantasai> Scribe+
<fantasai> TabAtkins: Useful to acknowledge if something is significantly difficult
<fantasai> TabAtkins: Here be dragons, when implementing
<TabAtkins> fantasai: i think they'll notice
<TabAtkins> astearns: would be good to have at least one example, hopefully we can find a real-world example
<TabAtkins> florian: could have a note which is less silly than my earlier phrasing. "CSSWG acknowledge that the interactino of this with line-breaking may be challenging to implement"
<TabAtkins> fantasai: or literally say "here be dragons"
<fantasai> s/or literally/or, as bkardell suggests, literally/
<TabAtkins> astearns: [restates proposed reoslution]
<TabAtkins> RESOLVED: autospacing happens *after* bidi-reordering, and we'll add a complex example to the spec