- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 04 Aug 2017 09:55:42 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Applying letter-spacing after line breaking`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: Applying letter-spacing after line breaking<br> <Rossen> github topic: https://github.com/w3c/csswg-drafts/issues/1509<br> <TabAtkins> koji: As fantasai just mentioned, diff between CSS2 and CSS3 is that 3 says apply l-s after bidi-reorder.<br> <TabAtkins> koji: But bidi-reorder applies after line-breaking,<br> <fantasai> CSS2.1 implied after bidi-reorder. L3 specifies explicitly<br> <TabAtkins> koji: Which can change the number of "between" spaces there is to add letter-spacing.<br> <TabAtkins> koji: So after we add letter-spacing, the line width can change, shorter or longer.<br> <TabAtkins> koji: So I think this is a worse issue than what it's trying to solve.<br> <TabAtkins> fantasai: You ahve to include the letter-spacing when figuring out sapcing and line-breaking.<br> <TabAtkins> fantasai: This is same as kerning.<br> <TabAtkins> koji: We don't redo kerning after bidi.<br> <TabAtkins> koji: Because changing line widths after break is really bad.<br> <TabAtkins> fantasai: Yeah, def don't want to change line-width afterwards, that's bad.<br> <TabAtkins> fantasai: So that measn you have to consider letter-spacing before breaking the line.<br> <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.<br> <TabAtkins> myles_: Do you have an example of this breaking?<br> <TabAtkins> koji: [looks it up]<br> <TabAtkins> koji: Last bit of example 16 in Text.<br> <TabAtkins> koji: There's a 2em spaccing between the characters in the span, but reordering separates the letters.<br> <TabAtkins> myles_: I understand now.<br> <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?<br> <TabAtkins> myles_: Ours won't cross bidi boundaries.<br> <TabAtkins> koji: We're trying to do better at shaping across element boundaries, but only in logical sequences, before bidi reordering.<br> <TabAtkins> koji: I believe we're trying to match Gecko's behavior.<br> <TabAtkins> fantasai: Yeah, difficult; we're splitting up letters in an element, so where does the letter-spacing go?<br> <TabAtkins> fantasai: Per spec, you don't put the letter spacing between letters of the element and letters outside the element.<br> <TabAtkins> fantasai: So I see you point that it's hard to measure correctly.<br> <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.<br> <TabAtkins> TabAtkins: line-right edge - in logical order, it separates the letter from the next logical letter.<br> <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?<br> <TabAtkins> <p>f_o_o<span>bar</span>_f_o_o</p><br> <TabAtkins> fantasai: Another span with borders and padding. You do linebreaking calcs.<br> <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?<br> <TabAtkins> <p>f_o_o_<span>bar</span>_f_o_o</p>, rather<br> <TabAtkins> koji: I was reading b-d-b for the first time this morning, and thought of that exact problem.<br> <TabAtkins> dbaron: Okay, at bidi *resolution* time, the element would split into two separate fragments, and thus both get borders.<br> <TabAtkins> koji: But you don't know how linebreaking will happen yet.<br> <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?<br> <TabAtkins> dbaron: We don't unclone them - they stay separate fragments.<br> <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<br> <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<br> <dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/5292<br> <TabAtkins> dbaron: That might not be an intentional decision; they might have thought about it as normal linebreaking and this behavior just falls out.<br> <TabAtkins> fantasai: I think it's okay to allow impls to do that.<br> <fantasai> TabAtkins: So the c and aleh would still be considered separate fragments, even though they are adjacent<br> <fantasai> TabAtkins: and the letter-spacing between them would be controlled by the parent<br> <fantasai> fantasai: I like this solution<br> <fantasai> TabAtkins: Wouldn't be too complicated, and would give sensible results in most cases and sensible-enough results in the rest<br> <fantasai> TabAtkins: During bidi resolution, you split them into separate fragments, and behavior falls out from that<br> <TabAtkins> koji: So we'll lose the letter sapcing between bidi runs.<br> <TabAtkins> TabAtkins: If the bidi runs are in the same element, yes - they'll use the parent's letter-spacing.<br> <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.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1509#issuecomment-320209074 using your GitHub account
Received on Friday, 4 August 2017 09:59:31 UTC