W3C home > Mailing lists > Public > public-css-archive@w3.org > April 2017

Re: [csswg-drafts] 'line-height: normal' definition should reflect reality of determining based on fonts

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Fri, 21 Apr 2017 08:38:59 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-296129092-1492763938-sysbot+gh@w3.org>
The CSS Working Group just discussed `'line-height: normal' definition should reflect reality of determining based on fonts`, and agreed to the following resolutions:

* `RESOLVED: add leading to union of ascent and descent`
* `RESOLVED: Replace definition of 'line-height: normal' with vaguer definition.`

<details><summary>The full IRC log of that discussion</summary>
&lt;astearns> topic: 'line-height: normal' definition should reflect reality of determining based on fonts<br>
&lt;astearns> github topic: https://github.com/w3c/csswg-drafts/issues/1254<br>
&lt;surma> Florian: we were trying to do things that depend on normal and it didn’t match reality<br>
&lt;surma> dbaron: spec says  that when you have glyphs from multiple fonts, where the fonts have different ascend and descend, the glyphs end up with different boxes<br>
&lt;fantasai> s/ascend/ascent/<br>
&lt;fantasai> s/descend/descent/<br>
&lt;fantasai> dbaron draws Chinese character and capital B, to represent glyphs from two fonts<br>
&lt;surma> dbaron: spec says that when you draw the background you use the lowest bottom and the highest top<br>
&lt;fantasai> dbaron draws misaligned boxes, representing the two different fonts that are triggered by fallback<br>
&lt;fantasai> dbaron labels height of tallest top to bottommost bottom as "content box"<br>
&lt;surma> dbaron: you add half of the ??? to each side (top/bottom) of the box<br>
&lt;fantasai> dbaron draws leading on each glyph; shorter glyph gets more half-leading on each side than taller glyph<br>
&lt;fantasai> dbaron labels distance from topmost edge of leading to bottommost leading edge as "line box contribution"<br>
&lt;surma> ScribeNick: fantasai<br>
&lt;fantasai> dbaron: Spec for normal says to use  a value between 1.0 and 1.2 as normal line-spacing<br>
&lt;fantasai> dbaron: This is not the Gecko behavior<br>
&lt;fantasai> dbaron: This is what the spec says<br>
&lt;fantasai> Florian: Spec contradicts itself<br>
&lt;fantasai> dbaron: Spec describes this behavior, and then says "therefore you get X" where X is not what you get out of this behavior<br>
&lt;fantasai> [confusion about earlier resolution from yesterday]<br>
&lt;fantasai> Florian: The other option was to reduce this line box contribution to just the value of the leading<br>
&lt;fantasai> Florian: which was, iirc, what Safari does,<br>
&lt;fantasai> (which is what Florian and fantasai thought we had resolved on yesterday)<br>
&lt;fantasai> myles: We never add padding to individual boxes. We do ceiling and flooring and then add leading at the end<br>
&lt;fantasai> dbaron: I'm fine with resolving on this, does make this other issue simpler<br>
&lt;fantasai> myles: I thought we resolved already<br>
&lt;fantasai> Florian: dbaron and Alan thought we resolved the other way<br>
&lt;fantasai> dbaron: 3d paragraph on 10.8.1 says to add half leading to each glyph. We're saying to add it to the content box<br>
&lt;fantasai> fantasai: Content box is not well-defined<br>
&lt;fantasai> dbaron: It's in 10.6.1.<br>
&lt;fantasai> dbaron: I guess it's not actually defined.<br>
&lt;fantasai> dbaron: So define that you add leading to union of ascent and descent<br>
&lt;fantasai> fantasai: What's an em box<br>
&lt;fantasai> dbaron: The thing we resolved gets you 15px lines, but only if you don't have a &lt;span> in your line<br>
&lt;fantasai> RESOLVED: add leading to union of ascent and descent<br>
&lt;fantasai> dbaron: What we're talking about is per inline box fragment<br>
&lt;fantasai> dbaron: Goal was to make lines 15px high<br>
&lt;fantasai> dbaron: This resolution will accomplish that given font fallback, as long as you have no markup whatsoever and every line is just a single box fragment<br>
&lt;fantasai> dbaron: The moment you have both markup and different font fallback in the different elements, it fails<br>
&lt;fantasai> dbaron: If you have for example<br>
&lt;fantasai> Get a taxi with &lt;span>京B&lt;/span><br>
&lt;fantasai> dbaron: Now you're computing the line-spacing for first piece separate from second piece<br>
&lt;fantasai> koji: In Blink, we use primary font to resolve content box<br>
&lt;fantasai> dbaron: We decided not to do that because wanted to consider all the glyphs<br>
&lt;fantasai> myles: If you have an element ... your entire line is that element<br>
&lt;fantasai> myles: what's primary font vs secondary font?<br>
&lt;fantasai> koji: If this is the example and no stying on &lt;span><br>
&lt;fantasai> koji: Then these two have same font family, then primary font is the same<br>
&lt;fantasai> koji: Even if this span starts from different font family, use the same font<br>
&lt;fantasai> dbaron: So you're saying you use the first available font<br>
&lt;fantasai> koji: If line height is not normal, yes<br>
&lt;fantasai> myles: Are you saying that you ignore the metrics of the non-primary font?<br>
&lt;fantasai> koji: yeah<br>
&lt;fantasai> myles: That's not what WebKit does<br>
&lt;fantasai> myles: At least I don't think so<br>
&lt;fantasai> koji: when we say we compute only once per inline box fragment, compute is based on which fonts?<br>
&lt;fantasai> Florian: Union of all the boxes<br>
&lt;fantasai> [more confusion]<br>
&lt;fantasai> dbaron redraws<br>
&lt;fantasai> dbaron: Let's say these are 16px glyphs and you want 20px line height<br>
&lt;fantasai> dbaron: with union thing, we take the tallst top of glyph, and lowest bottom of glyph<br>
&lt;fantasai> dbaron: Distance here is 19px<br>
&lt;fantasai> dbaron: To get to 20px, we add .5px to top and to bottom<br>
&lt;fantasai> dbaron: In some ways this isn't great, because it gives you baseline jitter when you have font fallback<br>
&lt;fantasai> dbaron: If you use only the primary font and not the others, you will not get baseline jitter<br>
&lt;fantasai> Florian: But you may get overlap<br>
&lt;fantasai> Florian: I think baseline jitter is preferable to overlap<br>
&lt;fantasai> dbaron: Generally the variation is not a lot, so unlikely to get overflow in most cases<br>
&lt;fantasai> dbaron: Unless you push your line height really close to 1.0<br>
&lt;fantasai> astearns: ?<br>
&lt;fantasai> myles: If you a really big paragraph, many lines of text, and one line in the middle has a character from a fallback font<br>
&lt;fantasai> dbaron: That will push the baseline of that line down, because centering union within the line height (19px) rather than just the primary font (16px)<br>
&lt;fantasai> myles: Webkit does that; we just have a little bit of jitter<br>
&lt;fantasai> dbaron: One other factor here...<br>
&lt;fantasai> dbaron: If we did only primary font, line-height-step would give you evenly-spaced baselines<br>
&lt;fantasai> dbaron: But if we don't, then even line-height-step won't give you evenly spaced baselines<br>
&lt;fantasai> myles: So the problem then is that if you use line-height-step, this middle line with the character, might trigger a double-spaced line<br>
&lt;fantasai> astearns: Sounds like maybe previous resolution, we don't want anymore<br>
&lt;fantasai> dbaron: Also could consider whether content-box should use primary font<br>
&lt;fantasai> dbaron: Let me finish<br>
&lt;fantasai> explanation<br>
&lt;fantasai> dbaron: There's a value called normal<br>
&lt;fantasai> dbaron: In theory this is a number<br>
&lt;fantasai> dbaron: But actually this is not what Gecko does<br>
&lt;fantasai> dbaron: Font has a metric that says what they thing the line spacing should be<br>
&lt;fantasai> myles: field is called line gap<br>
&lt;fantasai> dbaron: You could get the metric from the font and apply it to the glyph in that font, and then do the same with the other font to the other glyph<br>
&lt;fantasai> dbaron: And that would be easy with the previous behavior with per-glyph leading instead of union leading<br>
&lt;fantasai> Florian: Could do per-glyph leading and union it<br>
&lt;fantasai> dbaron: What gecko does is more horrible<br>
&lt;fantasai> dbaron: Gecko for line-height: normal<br>
&lt;fantasai> dbaron: Does per-glyph bounding box computation without external leading<br>
&lt;fantasai> dbaron: Then unions that with external leading of the primary font added to the glyph height of the primary font<br>
&lt;fantasai> dbaron: I don't think this was intentional<br>
&lt;fantasai> dbaron: so Gecko will take union of glyph boxes, and then unions that with leading box of the primary font<br>
&lt;fantasai> fantasai: maybe not so bad, gets you more regular spacing line to line, while still trying to avoid overlap by considering union of all glyph areas<br>
&lt;fantasai> Florian: I thought Koji had brought up earlier that for some languages there are very tall glyphs, and you may have that kind in the fallback<br>
&lt;fantasai> Florian: So might have something very tall and has external leading to get that to look nice<br>
&lt;fantasai> Florian: In these cases glyph can go beyond ascent and descent<br>
&lt;fantasai> Florian: Are these font metrics reliable<br>
&lt;fantasai> myles: Let's not discuss that<br>
&lt;fantasai> astearns: So...........<br>
&lt;fantasai> Florian: So spec says "line height number is like a numbe,r you just get to pick the number". This is not true<br>
&lt;fantasai> koji: Says use value that's appropriate to the font<br>
&lt;fantasai> koji: ...<br>
&lt;fantasai> koji: Second sentence is very questionable<br>
&lt;fantasai> dbaron: The sentences might ahve been written 10 years apart, as we edited CSS2<br>
&lt;fantasai> koji: “font of the element” is not defined<br>
&lt;fantasai> koji: earlier paragraph says UA may take all the fonts<br>
&lt;fantasai> used in the element<br>
&lt;fantasai> koji: this sentence doesn't make sense to me (second sentence)<br>
&lt;fantasai> koji: so I ignored it<br>
&lt;fantasai> koji: you read second sentence<br>
&lt;fantasai> myles: Should be fonts, not font, of the element<br>
&lt;fantasai> Florian: That's an improvement, but still undefined<br>
&lt;tantek> Indeed this has felt underspecified to me too<br>
&lt;fantasai> Florian: Based on it, but based how?<br>
&lt;fantasai> astearns: Vague is better than wrong<br>
&lt;fantasai> astearns: let's resolve to remove wrong parts<br>
&lt;fantasai> Florian quotes spec<br>
&lt;fantasai> discussion of prose<br>
&lt;fantasai> Spec is all wrong<br>
&lt;fantasai> Need to replace the entire definition<br>
&lt;fantasai> alan asks where new prose goes<br>
&lt;fantasai> fantasai: Errata CSS2, define in css-inline-3<br>
&lt;fantasai> myles: The reason we're discussing all of these computations is because if they were to differ you might get double spacing with line-height-step<br>
&lt;fantasai> myles: Because font metrics differ between browsers *and* platforms, will still get differences<br>
&lt;fantasai> Florian: Because we don't have a foundational model from which to discuss issues<br>
&lt;fantasai> koji: Changing defintion for non-normal case is easier.. doesn't chnage layout<br>
&lt;fantasai> koji: Just changes glyph position within the line<br>
&lt;fantasai> koji: but if we change definition of normal, might break lots of sites<br>
&lt;fantasai> astearns: Well, we need to change the definition in the spec in any case, because it's not matching what browsers do<br>
&lt;fantasai> astearns: So proposed resolution is to remove wrong definition of normal, and replace with more accurate definition<br>
&lt;fantasai> fantasai: Will need to be vague<br>
&lt;fantasai> astearns: Any objection to a vague but not wrong defintion of 'line-height: normal'?<br>
&lt;fantasai> RESOLVED: Replace definition of 'line-height: normal' with vaguer definition.<br>
&lt;fantasai> dbaron: Basically need to say that 'normal' does something based on the font that overrides algorithm for number<br>
&lt;fantasai> myles: Say all the fonts may be consulted, and line gap of all the fonts may be consulted<br>
&lt;fantasai> ACTION fantasai: make wording<br>
&lt;trackbot> Created ACTION-849 - Make wording [on Elika Etemad - due 2017-04-28].<br>
&lt;fantasai> Florian: Previous resolution, koji said it's not what they do<br>
&lt;fantasai> dbaron: Matches Safari, not blink or gecko<br>
&lt;fantasai> dbaron: Makes rhythm better wrt what spec previously said, but worse wrt blink/gecko<br>
&lt;fantasai> dbaron: Also only helps if you have no elements<br>
&lt;fantasai> discussion of what's better than what<br>
&lt;fantasai> dbaron: It could lead to glyph box overlap where there wasn't before<br>
&lt;fantasai> dbaron: You could end up now with negative half-leading<br>
&lt;fantasai> dbaron: Because before leading would definitely be positive<br>
&lt;fantasai> astearns: My understanding was that we were going to size on the content box<br>
&lt;fantasai> dbaron: content-box is should, not definite<br>
&lt;fantasai> astearns: need to discuss content box...<br>
&lt;fantasai> astearns: Does that affect the previous resolution?<br>
&lt;fantasai> dbaron: Other factor with content box<br>
&lt;fantasai> dbaron: tend not to have padding and border, but backgrounds is common<br>
&lt;fantasai> dbaron: Whether to include fallbak glyphs  in content box...<br>
&lt;fantasai> dbaron: Do you want fallback glyphs to potentially overflow content box?<br>
&lt;fantasai> dbaron: Or do we want to make sure content boxes are consistent across multiple elements?<br>
&lt;fantasai> koji: I would really want to make heights of lines consistent. Don't care so much about positioning within the line<br>
&lt;fantasai> Florian: If we don't do the resolution we've just taken, the line height may be bigger than the one you asked for. With this resoution, if you say line-height: 20x, you always get 20px<br>
&lt;fantasai> koji doesn't believe this, so Florian is trying to explain it again<br>
&lt;fantasai> ...<br>
&lt;tantek> There is an inevitable design tension between "do exactly what I said" and maintaining a strict rhythm, and avoiding overlapping pixels / text. Not sure how that tension can be resolved in a predictable way. Especially with cross-platform/browser font differences, font substitutions etc.<br>
&lt;tantek> I don't have a specific suggestion, but I'm curious what methodology the group uses to try to resolve this tension.<br>
&lt;fantasai> tantek, in general we tend to go with "make it readable" over "make it pretty"<br>
&lt;fantasai> There are several diagrams on the board now<br>
&lt;tantek> fantasai, I agree with that. I'm more wondering about the "[ CSS is Awe ] some" type problems<br>
&lt;fantasai> Blue one represents "use the primary font for size and position"<br>
&lt;fantasai> Black one is "apply leading to each glyph and take union of all"<br>
&lt;fantasai> Red one is "union glyph boxes and apply leading (could be negative)"<br>
&lt;fantasai> dbaron: Red and blue will both give consistent line sizes, but blue will give consistency even when you have &lt;span>s<br>
&lt;tantek> fantasai, cool re: diagrams. I'll check the archives later for that. Thanks and good luck!<br>
&lt;fantasai> In blue and Red cases, could get overflow...<br>
&lt;fantasai> in blue case the overflow is all wrt primary font. Red case clips a bit from tallest and lowest bits of the combination<br>
&lt;fantasai> Florian summarizes and asks Rossen, who suspects they don't ignore fallback so probably black or red<br>
&lt;fantasai> dbaron notes this is for non-normal values<br>
&lt;fantasai> astearns: We should have description in CSS2.1 with what browsers do, so we're actually describing reality<br>
&lt;fantasai> ACTION Rossen Verify what is done by each browser (by checking Edge and putting on WG to-do list for everyone else)<br>
&lt;trackbot> Created ACTION-850 - Verify what is done by each browser (by checking edge and putting on wg to-do list for everyone else) [on Rossen Atanassov - due 2017-04-28].<br>
&lt;fantasai> astearns: Anything else?<br>
&lt;fantasai> Meeting closed.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1254#issuecomment-296129092 using your GitHub account
Received on Friday, 21 April 2017 08:39:07 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:11 UTC