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