[css-text] letter-spacing and word-spacing applied to which side?

[kojiishi]

This test: http://jsbin.com/botezog/edit?html,output
indicates that:

• Edge and WebKit applies to to line-right direction.
• Gecko and Blink applies to the end side of bidi resolved direction.

Which is desired?

Note: On first post, Edge and WebKit behavior was thought "to the end side of CSS direction property", but it turned to be wrong, updated the description above.

[dbaron]

The spec did a good bit of work to improve the behavior, since the current Gecko behavior is definitely not optimal (and we get bug reports on it). What the spec requires is more complicated than either of the above, but it's something we'd like to implement at some point.

[kojiishi]

The spec did a good bit of work to improve the behavior

Thank you, great to know it's defined!! I re-read but can't understand which parts define this. Could you mind to explain a bit more?

but it's something we'd like to implement at some point

If Gecko is willing to match to Edge and WebKit, I'm happy for Blink to match too. So spacing should be applied to which CSS direction property specifies, not to which bidi algorithm resolved?

[aharon-lanin]

As far as I can see, what the spec says for letter-spacing is this:
"This property specifies additional spacing between adjacent characters (commonly called tracking). Letter-spacing is applied after bidi reordering and is in addition to any ‘word-spacing’. Letter-spacing must not be applied at the beginning or at the end of a line."

Thus, if uppercase letters represent RTL characters and lowercase represents LTR, and we have a direction:ltr block with the content "ABcdEF", the bidi reordering is "BAcdFE", and the letter-spacing should be applied between B and A, A and c, c and d, d and F, and F and E. It should not be applied at the beginning or end of the block.

That Gecko and Blink apply the spacing to the left of the ג in http://jsbin.com/botezog/edit?html,output is incorrect. As the spec says, "It should not be applied at the beginning or end of the block."

Worse, putting the spacing at "the end side of the bidi resolved direction", results in Gecko and Blink putting no spacing between A and c, and double spacing between d and F in the example above, which one can see at http://jsbin.com/cajanimahu/edit?html,output. The spacing should be even throughout.

If Edge and WebKit put the spacing at "the end side of CSS direction property" (which I currently have no easy way of verifying), their behavior isn't correct either. That is, they will do better than Gecko and Blink for http://jsbin.com/cajanimahu/edit?html,output, but will make the same mistake once the direction for the middle run is indicated explicitly in markup, as in http://jsbin.com/hiqesujaga/edit?html,output.

IMHO, letter-spacing is pretty much unusable in Gecko and Blink when applied to a mixture of LTR and RTL characters. Edge and WebKit should do better, but that too breaks down once the content contains explicit direction markup.

As for word spacing, the spec says "Additional spacing is applied to each word separator left in the text after the white space processing rules have been applied, and should be applied half on each side of the character". As far as I can tell, this definition is completely bidi-transparent.

And as far as I can tell from http://jsbin.com/jukudaxewa/edit?html,output, Gecko and Blink seem to get it pretty much right - except that Blink also seems to put word spacing after the trailing character in the last line; I have no idea why.

[kojiishi]

Thank you @aharon-lanin, I added your samples to the original test http://jsbin.com/botezog/edit?html,output and also added case when paragraph dir is RTL.

For begin/end of block, it's #1518. All 4 browsers do it differently from the spec that I think we need to be careful to change.

For the desired behavior, yeah, you're right, I forgot the very basic requirement that all spaces should be consistent regardless of bidi reordering. At least for the 6 cases in the test, Edge and WebKit does it right, while Blink and Gecko don't, so my observation in the original comment on Edge/WebKit might be inaccurate. Maybe they always apply to the right? I guess I need more tests to verify that.

I haven't understood how to implement what the spec says today (#1509), but you gave me a great advice to think further, thank you about this. I hope we can discuss and clarify the spec better, or come up with a good solution for bidi.

word-spacing is easy, since spacing is applied to space characters. Blink doesn't apply half-and-half, but since it's a space character, it normally doesn't matter (unless author use some special font where space is not a space.) I haven't given much thoughts on it yet, but your confirmation was a great help.

[kojiishi]

Confirmed WebKit adds letter-spacing to line-right direction.

[kojiishi]

Given the @aharon-lanin's comment:

IMHO, letter-spacing is pretty much unusable in Gecko and Blink when applied to a mixture of LTR and RTL characters.

I'm leaning to align Blink to Edge/WebKit until I understand other open issues.

[fantasai]

Koji, either align to the spec or insist on a change to the spec. Random implementers arbitrarily picking their favorite engine to copy while ignoring the spec is not a positive method for standardizing behavior. The spec, afaict, is very clear about the desired results. How you implement them is entirely up to you.

[kojiishi]

@fantasai I think you misunderstood. This depends on #1518, which looks like it needs more discussions. I'm just saying until the spec reaches more stable.

[kojiishi]

@SebastianZ commented in #1518:

I'd say the behavior should be aligned first, so it's easier to add the new values.

and this issue is about one non-interoperable behavior we could align before we discuss adding a new behavior (if WG agreed to add a new behavior.)

Your proposed syntax has inline-start and inline-end:

letter-spacing: normal | <length> [ inline-start || inline-end ]?

but what impls do today are (from my testing, maybe inaccurate):

• Blink and Gecko add spacing to the end-side of bidi resolved direction. This is different from inline-end, like when <span dir=rtl>english</span>, inline-end is left but "the end-side of bidi resolved direction" is right.
• Edge and WebKit add spacing to the line-right.

Given @aharon-lanin's comment above:

IMHO, letter-spacing is pretty much unusable in Gecko and Blink when applied to a mixture of LTR and RTL characters.

I think Blink can try to change to Edge/WebKit behavior to see if people complaints. This change doesn't affect the width of line, just which side spacing appears, and the current behavior is said "unusable", so I think this is a safe change.

Would you be willing to align Gecko to Edge/WebKit on this regard? If yes, we can make this interoperable and explainable using keywrods like line-right. If Gecko doesn't agree, hmm, that's hard. We probably need to seek for a behavior where 4 impls can agree to align to.

[css-meeting-bot]

The CSS Working Group just discussed letter-spacing and word-spacing applied to which side, and agreed to the following resolutions:

• RESOLVED: No change, Blink/Gecko require bugfixes.

The full IRC log of that discussion

<Rossen> Topic: letter-spacing and word-spacing applied to which side
<Rossen> github topic: https://github.com//issues/1517
<TabAtkins> koji: Problem from user perspective is that when letter-spacing is applied to a bidi-mixed string, Blink and Gecko has sometimes no l-s, sometimes double l-s, it's hard to predict.
<TabAtkins> koji: WK and Edge add even letter-spacing.
<TabAtkins> koji: It's not specced in CSS2, CSS3 defines quite different algorithm that solves this problem.
<myles_> q+
<TabAtkins> koji: But it requires some complex impl.
<TabAtkins> fantasai: CSS3 just says letter-spacing is applied after bidi reordering.
<TabAtkins> myles_: If we end up shipping what we resolved in the last topic, I tink that'll mean that the Blink behavior of switching which direction you add l-s to, you won't need anymore.
<fantasai> https://www.w3.org/TR/CSS21/text.html#spacing-props
<TabAtkins> myles_: bc then letter-spacing isn't on "left" or "right", it's on "inside".
<TabAtkins> fantasai: 2.1 defines it as "between characters" - double or nothing is just wrong.
<fantasai> CSS2.1 defines letter-spacing as "between" characters
<TabAtkins> CSS3 is more precise "between adjacent typographic characters, after bidi reordering". No ambiguity.
<fantasai> https://drafts.csswg.org/css-text-3/#letter-spacing-property
<TabAtkins> s/CSS3/fantasai: CSS3/
<TabAtkins> myles_: So what's the proposal, making it legal to have double/nothing?
<TabAtkins> koji: Proposal is to match WK/Edge.
<TabAtkins> myles_: Oh, okay, great.
<TabAtkins> myles_: So that's what the spec already says, right?
<TabAtkins> koji: If spec says between chars, this might be an impl issue.
<TabAtkins> koji: Most impls apply it to the left or right of characters.
<TabAtkins> koji: Edge and WK apply it to the line-right direction, so always "to the right" regardless of direction.
<TabAtkins> fantasai: ANd if we apply the previous topic's resolution, the user can't tell whether it's line-left/right.
<TabAtkins> koji: Blink/Gecko apply it to end edge.
<TabAtkins> Florian: Can't you detect it with backgrounds?
<TabAtkins> fantasai: No, l-s doesn't occur at a boundary; the l-s at a boundary is determined by the element containing both of them.
<koji> s/end edge/end side of resolved bidi direction/
<TabAtkins> dbaron: I think the current spec is solid, just a decent bit of work to implement.
<TabAtkins> astearns: So reading of issue is just that Blink/Gecko need to change behavior to match spec?
<TabAtkins> koji: Yes.
<TabAtkins> RESOLVED: No change, Blink/Gecko require bugfixes.