Repository navigation
[css-text] Letter spacing is inserted after RTL reordering #1509
Description
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?
Activity
fantasai commentedon Jun 21, 2017
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.
kojiishi commentedon Jun 22, 2017
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...)
kojiishi commentedon Jun 22, 2017
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
FremyCompany commentedon Jul 12, 2017
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.
kojiishi commentedon Jul 12, 2017
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.
css-meeting-bot commentedon Aug 4, 2017
The CSS Working Group just discussed
Applying letter-spacing after line breaking.The full IRC log of that discussion
<TabAtkins> Topic: Applying letter-spacing after line breaking<Rossen> github topic: https://github.com//issues/1509
<TabAtkins> koji: As fantasai just mentioned, diff between CSS2 and CSS3 is that 3 says apply l-s after bidi-reorder.
<TabAtkins> koji: But bidi-reorder applies after line-breaking,
<fantasai> CSS2.1 implied after bidi-reorder. L3 specifies explicitly
<TabAtkins> koji: Which can change the number of "between" spaces there is to add letter-spacing.
<TabAtkins> koji: So after we add letter-spacing, the line width can change, shorter or longer.
<TabAtkins> koji: So I think this is a worse issue than what it's trying to solve.
<TabAtkins> fantasai: You ahve to include the letter-spacing when figuring out sapcing and line-breaking.
<TabAtkins> fantasai: This is same as kerning.
<TabAtkins> koji: We don't redo kerning after bidi.
<TabAtkins> koji: Because changing line widths after break is really bad.
<TabAtkins> fantasai: Yeah, def don't want to change line-width afterwards, that's bad.
<TabAtkins> fantasai: So that measn you have to consider letter-spacing before breaking the line.
<TabAtkins> fantasai: But since bidi-reordering happens after breaking the line, you won't know where the letter-sapcing goes until after doing the reordering.
<TabAtkins> myles_: Do you have an example of this breaking?
<TabAtkins> koji: [looks it up]
<TabAtkins> koji: Last bit of example 16 in Text.
<TabAtkins> koji: There's a 2em spaccing between the characters in the span, but reordering separates the letters.
<TabAtkins> myles_: I understand now.
<TabAtkins> fantasai: If you have that example, bidi-reordering puts two letters nexxt to each other that weren't next to each other logically, do you perform shaping and kerning between them?
<TabAtkins> myles_: Ours won't cross bidi boundaries.
<TabAtkins> koji: We're trying to do better at shaping across element boundaries, but only in logical sequences, before bidi reordering.
<TabAtkins> koji: I believe we're trying to match Gecko's behavior.
<TabAtkins> fantasai: Yeah, difficult; we're splitting up letters in an element, so where does the letter-spacing go?
<TabAtkins> fantasai: Per spec, you don't put the letter spacing between letters of the element and letters outside the element.
<TabAtkins> fantasai: So I see you point that it's hard to measure correctly.
<TabAtkins> koji: If we follow Edge/WK impl and resolve the previous l-s topic, there should be 2em space on the right of C.
<TabAtkins> TabAtkins: line-right edge - in logical order, it separates the letter from the next logical letter.
<TabAtkins> fantasai: Example: you ahve a para with 1em letter spacing. Inside you have a span with 0 l-s. Between the last letter of the span and first letter outside the span, there's 1em letter spacing, where does that attach?
<TabAtkins> <p>f_o_o<span>bar</span>_f_o_o</p>
<TabAtkins> fantasai: Another span with borders and padding. You do linebreaking calcs.
<TabAtkins> fantasai: Then you cut the line and do bidi reordering, but it has b-d-b: clone. Now you have two pieces with padding around them, where befor eyou had only one. Now what?
<TabAtkins> <p>f_o_o_<span>bar</span>_f_o_o</p>, rather
<TabAtkins> koji: I was reading b-d-b for the first time this morning, and thought of that exact problem.
<TabAtkins> dbaron: Okay, at bidi *resolution* time, the element would split into two separate fragments, and thus both get borders.
<TabAtkins> koji: But you don't know how linebreaking will happen yet.
<TabAtkins> TabAtkins: If there's only enough room for 4 letters, so the "c" and the aleph are next to each other, is that still two independent spans?
<TabAtkins> dbaron: We don't unclone them - they stay separate fragments.
<dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Aspan%20%7B%20border%3A%20medium%20solid%20blue%3B%20background%3A%20aqua%3B%20%7D%0A%3C%2Fstyle%3E%0A%3Cp%3Eab%3Cspan%3Ec%D7%90%3C%2Fspan%3E%D7%91%D7%92%3C%2Fp%3E%0A%3Cp%3Eab%3Cspan%20style%3D%22box-decoration-break%3Aclone%22%3Ec%D7%90%3C%2Fspan%3E%D7%91%D7%92%3C%2F
<dbaron> p%3E%0A%3Cp%3Eab%3Cspan%20style%3D%22box-decoration-break%3Aclone%22%3Ec%D7%90%3C%2Fspan%3E%3Cbr%3E%D7%91%D7%92%3C%2Fp%3E
<dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/5292
<TabAtkins> dbaron: That might not be an intentional decision; they might have thought about it as normal linebreaking and this behavior just falls out.
<TabAtkins> fantasai: I think it's okay to allow impls to do that.
<fantasai> TabAtkins: So the c and aleh would still be considered separate fragments, even though they are adjacent
<fantasai> TabAtkins: and the letter-spacing between them would be controlled by the parent
<fantasai> fantasai: I like this solution
<fantasai> TabAtkins: Wouldn't be too complicated, and would give sensible results in most cases and sensible-enough results in the rest
<fantasai> TabAtkins: During bidi resolution, you split them into separate fragments, and behavior falls out from that
<TabAtkins> koji: So we'll lose the letter sapcing between bidi runs.
<TabAtkins> TabAtkins: If the bidi runs are in the same element, yes - they'll use the parent's letter-spacing.
<fantasai> 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.
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.
kojiishi commentedon Aug 15, 2017
@fantasai can you help to understand? I understand the proposal solves
border-decoration-break: clone, but I can't see how it solvesletter-spacing. By looking at Example 16, so the proposal is to create (assume<f>is the internal fragment):The common ancestor of
candג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
candא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 withcorא?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.
fantasai commentedon Mar 8, 2018
Talked with Koji; Agenda+ to resolve on proposal in #1509 (comment)
FremyCompany commentedon Mar 10, 2018
I see the Agenda+ but I don't see an example explaining this new proposed algorithm. I'd like an image explaining this if possible, or at least a more detailed proposal, because I'm not confident on resolving on something I don't understand.
fantasai commentedon Mar 14, 2018
@FremyCompany It means that in Koji's example above, if we ignore the
<f>bits:Because the span will split into two fragments due to bidi reordering on an infinite line, then even if the last two letters don't fit and the two pieces happen to end up together, they are considered to be of two different fragments, and the space between the two letters will be considered to come from the P (the letters’ nearest common ancestor).
9 remaining items
[css-writing-modes] Clarify when bidi induces fragmentation of an inl…
[css-text-3] tests for letter-spacing
[css-text-3] tests for letter-spacing (#13397)
Bug 1496849 [wpt PR 13397] - [css-text-3] tests for letter-spacing, a…
Bug 1496849 [wpt PR 13397] - [css-text-3] tests for letter-spacing, a…
Bug 1496849 [wpt PR 13397] - [css-text-3] tests for letter-spacing, a…
Bug 1496849 [wpt PR 13397] - [css-text-3] tests for letter-spacing, a…
Bug 1496849 [wpt PR 13397] - [css-text-3] tests for letter-spacing, a…
Bug 1496849 [wpt PR 13397] - [css-text-3] tests for letter-spacing, a…