The last example of Example 16 in letter-spacing property says:

Letter spacing is inserted after RTL reordering

But letter-spacing affects line breaking, so we need to compute before line breaking.

Is this saying, compute once for line breaking in logical order, then re-compute after line breaking in visual order? Then the line width will not match and it may result in large-lagged lines, correct?

Test: http://output.jsbin.com/hudaxi

Technically, bidi reorder affects line breaking as well, since adjacent letters can have kerning and other effects that alter their width. :) This is not a different consideration. Letter-spacing is at least more predictable than that.

We don't compute kerning/joining/etc. using adjacent characters after re-order for the same reason. The current engine can't do it across bidi runs, new engine does it in logical order. Doing them after re-order looks degration to me.

Thank you for the comment, your comment confirmed I'm not misunderstanding nor misreading (unless I'm still misunderstanding something...)

I heard Mozilla is going to implement this, is that correct? @dbaron @SebastianZ

At first this was asking clarification but now we seem to have the same understanding, just different opinion which is more important.

Do other impls have opinions? @litherum @FremyCompany

I haven't seen letter-spacing usages in the wild that require complex rules for it.

That doesn't mean there are no such use cases; but I think due to widespread abuse letter-spacing is not a good candidate for being "fixed" at this point.

Thank you @FremyCompany, I'm hearing similar feedback from our engineer too.

I don't know the whole issue list the current design is trying to solve, maybe the list is much longer than I'm guessing. I'm hoping, in Paris, we try to learn the history from whoever knows and discuss 1) whether compat is needed or not, and 2) given that information, possible simplification of the algorithm by focusing more important issues in existing impls.

I hope we can reach consensus easier if this is compat with existing impls, and additions are simpler.

The CSS Working Group just discussed Applying letter-spacing after line breaking.

Proposed that bidi resolution would result in splitting an inline in infinite space will always create two fragments, even if they end up adjacent due to line breaking.

Behavior for letter-spacing (and other things affected, like box-decoration-break), falls out of this definition: in this case, if the two letters end up adjacent but are part of different fragments, the spacing between them will be given by the parent (according to the letter-spacing rules that control letter-spacing at element boundaries). This avoids the measuring problem.

@fantasai can you help to understand? I understand the proposal solves border-decoration-break: clone, but I can't see how it solves letter-spacing. By looking at Example 16, so the proposal is to create (assume <f> is the internal fragment):

<p><f>ab</f><span><f>c</f><f>א</f></span><f>בג</f></p>

The common ancestor of c and ג is <p>, so there will be no 2em spacing in the result, if I'm not mistaken.

Or is your proposal includes to change to check logical adjacent character instead of visual adjacent character? Then between c and א has 2em space, but I can't read from the current spec where that space should go after re-order. Should it be re-ordered along with c or א?

Could you point out what I missed?

For your question in F2F, if we were to say "apply to line-right of characters", we could say, for the last character, apply the spacing of common ancestor. I'm ok to use the current way to define it if you can make it to work, but if you prefer the line-right solution, I hope this can work.