- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 07 Nov 2017 01:47:46 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `https://github.com/w3c/csswg-drafts/issues/1796`, and agreed to the following resolutions: * `RESOLVED: Take florians proposed change to definitive line heights.` * `RESOLVED: Take florians proposed change for line-height normal.` <details><summary>The full IRC log of that discussion</summary> <florian> Topic: https://github.com/w3c/csswg-drafts/issues/1796<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/1796<br> <eae> florian: This is a meta issues, many issues linked from it. Want to work on that css 2.1 doesn't define how line height is calculated. It tries to but contradicts with itself.<br> <eae> florian: I've written a bunch of tests to see what browsers actually do. Much more interop between browsers than expected.<br> <eae> florian: I'm not talking about which font metrics are used. Separate discussion,<br> <eae> florian: I'm also not talking about when we have multiple inline elements within a line. Several fonts with different glyphs within a line, how are they algned? That is what I'm talking about.<br> <eae> florian: There are two general cases where line height is normal or has a value, resolves to specific size. Then there is normal.<br> <eae> florian: In case where it is a size, you get exactly that size. Not clear from spec. Some spec text suggest it shoud be union of that per font, no browser does that.<br> <eae> florian: The baselines from the first font is used and everyhting else is aligned from there. Not what the spec says but it is what all UAs do. That is good.<br> <eae> astearns: Is it worth resolving to change spec to match that?<br> <eae> florian: Yes.<br> <eae> florian: Have proposed wording. If enough people have looked at my tests to verify them I'd be happy to resolve.<br> <eae> florian: We have to be very specific when patching css 2.1<br> <eae> florian: Happy to craft detailed diff if we agree on the high level issue<br> <eae> eae: Matches our behavior<br> <eae> myles: We should just make the change and revisit if it causes problems.<br> <eae> florian: The specific proposal is listed in issue 1801 at the bottom.<br> <florian> https://drafts.csswg.org/css2/visudet.html#leading<br> <eae> dbaron: I was still looking at the previous issue.<br> <eae> florian: One is about size, the other about alignment.<br> <eae> florian: "When the value of the line-height property is something other than normal, determine the leading L to add, where L = 'line-height' - AD of the first available font. Half the leading is added above A of first available font and the other half below D of first available font, giving the glyph and its leading a total height above the baseline of A' = A + L/2 and a total depth of D' = D + L/2. Glyphs from fonts other that the first available font do<br> <eae> not impact the height of the inline box."<br> <eae> dbaron: I think that seems resoanble. You might even want to say height or baseline of the inline box.<br> <eae> dbaron: There might be some cases where that is not what we do but think that is for normal line height. Seems reasonable to me.<br> <eae> astearns: Next step would be?<br> <eae> florian: Resolve if we agree.<br> <eae> astearns: and then we can review that pull request?<br> <eae> RESOLVED: Take florians proposed change to definitive line heights.<br> <eae> florian: CSS 2.1, in some cases, claims that line height normal behaves the same way as defined with a specific value. Probably between 1 and 1.5. Not what browsers do. What UAs do is take all fonts that are used, plus the first font, even if not used. That is what everybody does. Not what CSS 2.1 clains.<br> <eae> github issue: https://github.com/w3c/csswg-drafts/issues/1802<br> <eae> dbaron: I have a vague memory of gecko doing this in some cases. If there is a simpler impl I'd be happy to change.<br> <eae> florian: Only case I could find that skipped first font if unicode range is used for the first font. Chrome and Gecko have different behaviors. Other then that and the case where the first font' doesn't have the space glyph there is full interop.<br> <eae> astearns: Has anyone reviewed these tests?<br> <eae> florian: frenemy said he did.<br> <eae> astearns: Is Edge fine with taking this change? And Chrome?<br> <eae> eae: Yes<br> <eae> myles: Let's do it!<br> <eae> dbaron: Go ahead, trying to figure it out will take awhile.<br> <eae> astearns: Any objections?<br> <eae> dbaron: I'm pretty sure the gecko behavior is too weird. Might be worth having test coverage.<br> <eae> florian: There is 2.5 browsers doing one thing, 1.5 the other.<br> <eae> RESOLVED: Take florians proposed change for line-height normal.<br> <eae> github issue: https://github.com/w3c/csswg-drafts/issues/1798<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1798#issuecomment-342348956 using your GitHub account
Received on Tuesday, 7 November 2017 01:47:53 UTC