Re: [csswg-drafts] [css-text] letter-spacing and word-spacing applied to which side?

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.`

<details><summary>The full IRC log of that discussion</summary>
&lt;Rossen> Topic: letter-spacing and word-spacing applied to which side<br>
&lt;Rossen> github topic: https://github.com/w3c/csswg-drafts/issues/1517<br>
&lt;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.<br>
&lt;TabAtkins> koji: WK and Edge add even letter-spacing.<br>
&lt;TabAtkins> koji: It's not specced in CSS2, CSS3 defines quite different algorithm that solves this problem.<br>
&lt;myles_> q+<br>
&lt;TabAtkins> koji: But it requires some complex impl.<br>
&lt;TabAtkins> fantasai: CSS3 just says letter-spacing is applied after bidi reordering.<br>
&lt;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.<br>
&lt;fantasai> https://www.w3.org/TR/CSS21/text.html#spacing-props<br>
&lt;TabAtkins> myles_: bc then letter-spacing isn't on "left" or "right", it's on "inside".<br>
&lt;TabAtkins> fantasai: 2.1 defines it as "between characters" - double or nothing is just wrong.<br>
&lt;fantasai> CSS2.1 defines letter-spacing as "between" characters<br>
&lt;TabAtkins> CSS3 is more precise "between adjacent typographic characters, after bidi reordering". No ambiguity.<br>
&lt;fantasai> https://drafts.csswg.org/css-text-3/#letter-spacing-property<br>
&lt;TabAtkins> s/CSS3/fantasai: CSS3/<br>
&lt;TabAtkins> myles_: So what's the proposal, making it legal to have double/nothing?<br>
&lt;TabAtkins> koji: Proposal is to match WK/Edge.<br>
&lt;TabAtkins> myles_: Oh, okay, great.<br>
&lt;TabAtkins> myles_: So that's what the spec already says, right?<br>
&lt;TabAtkins> koji: If spec says between chars, this might be an impl issue.<br>
&lt;TabAtkins> koji: Most impls apply it to the left or right of characters.<br>
&lt;TabAtkins> koji: Edge and WK apply it to the line-right direction, so always "to the right" regardless of direction.<br>
&lt;TabAtkins> fantasai: ANd if we apply the previous topic's resolution, the user can't tell whether it's line-left/right.<br>
&lt;TabAtkins> koji: Blink/Gecko apply it to end edge.<br>
&lt;TabAtkins> Florian: Can't you detect it with backgrounds?<br>
&lt;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.<br>
&lt;koji> s/end edge/end side of resolved bidi direction/<br>
&lt;TabAtkins> dbaron: I think the current spec is solid, just a decent bit of work to implement.<br>
&lt;TabAtkins> astearns: So reading of issue is just that Blink/Gecko need to change behavior to match spec?<br>
&lt;TabAtkins> koji: Yes.<br>
&lt;TabAtkins> RESOLVED: No change, Blink/Gecko require bugfixes.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1517#issuecomment-320204087 using your GitHub account

Received on Friday, 4 August 2017 09:44:56 UTC