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

Re: [csswg-drafts] [css21][css-inline] height of the content area of inline level boxes

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Tue, 07 Nov 2017 06:33:30 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-342389094-1510036409-sysbot+gh@w3.org>
The Working Group just discussed `github issue: none`, and agreed to the following resolutions:

* `RESOLVED: To define first available font more strictly  in the fonts model and leave it undefined in 2.1`
* `RESOLVED: Change the wording such that 2.1 is saying you should define the content area based on the first available font and only that font.`

<details><summary>The full IRC log of that discussion</summary>
&lt;eae> topic: github issue: none<br>
&lt;eae> dbaron: Want to go back to line height normal. In some cases we use different font metrics.<br>
&lt;eae> dbaron: The text in the proposal was very specific about the metric.<br>
&lt;eae> florian: Will update it to be more clear about the specifics and that the font metrics in question isn't defined.<br>
&lt;eae> dbaron: What metrics are used should be looked at separately. Will add comment.<br>
&lt;eae> github issue: https://github.com/w3c/csswg-drafts/issues/1798<br>
&lt;eae> florian: We discussed whether the first font in the fallback list should count as the first available font even if it doens't have a space glyph. We did not specify whether it should also apply to line height.<br>
&lt;eae> florian: Safari, Edge, and FF half the time consideres it even if it doesn't have a space glyph.<br>
&lt;eae> florian: Safari and Chrome does not.<br>
&lt;fremy> q+<br>
&lt;eae> fantasai: The first available font should have a strict consistent definition across specs.<br>
&lt;eae> florian: Is not consistent across implementations.<br>
&lt;Rossen> q?<br>
&lt;eae> florian: Happy to change if implementations are willing to change.<br>
&lt;eae> florian: I don't really care strongly, arguments on both sides.<br>
&lt;eae> florian: Are edge and safari ok with that?<br>
&lt;eae> fremy: I didn't run all of the tests but I think we do the same thing?<br>
&lt;eae> florian: So there are three compat implementations?<br>
&lt;eae> florian: The first available font wording is used in 2.1 just not defined.<br>
&lt;eae> astearns: Might be acceptable to not test the presence of space in 2.1<br>
&lt;eae> florian: Define it in fonts3 and then have that definition apply to all cases where we mention first available font<br>
&lt;eae> Proposed Resolution: To define first available font more strictly  in the fonts model and leave it undefined in 2.1<br>
&lt;eae> RESOLVED: To define first available font more strictly  in the fonts model and leave it undefined in 2.1<br>
&lt;eae> github issue: none<br>
&lt;eae> florian: All browsers agree that the size of the content area depends on the size of the primary font, even if no characters from the primary font are used.<br>
&lt;eae> florian: The specification doesn't define the behavior, say "may do A or B".<br>
&lt;eae> florian: Should remove "may do A" as no browser does that.<br>
&lt;eae> florian: Suggest we remove suggestion saying that one may do something that nobody does.<br>
&lt;eae> dbaron: Would argue it should be a SHOULD rather than MUST instead of a MAY.<br>
&lt;eae> myles: Content area also depends on the line-gap property<br>
&lt;eae> florian: Just depends on font metrics.<br>
&lt;eae> florian: Spec says "do whatever you want, here are two suggestions". Doesn't mandate a specific metric.<br>
&lt;eae> myles: Shouldn't say ascent or decent, have specific meaning.<br>
&lt;eae> dbaron: I don't think this ones includes line gap, only asc+dsc.<br>
&lt;eae> github issue: https://github.com/w3c/csswg-drafts/issues/1804<br>
&lt;eae> florian: There is a paragraph saying that if more fonts are used the height of the area isn't defined but we suggest... I propose we remove that.<br>
&lt;eae> Rossen: What about overflow?<br>
&lt;eae> florian: People don't do that for background I think.<br>
&lt;eae> Rossen: I'll follow up with a test case.<br>
&lt;dbaron> FYI, I did figure out the crazy Gecko behavior I was trying to remember: https://github.com/w3c/csswg-drafts/issues/1802#issuecomment-342349505<br>
&lt;eae> astearns: Let's continue making tests given the number of questions raised.<br>
&lt;eae> fantasai: This is about where the backgorund is painted for inline elements, very specifically about backgrounds.<br>
&lt;eae> Rossen: I might be miss-reading the issue.<br>
&lt;myles> dauwhe: don't worry, computers are fast<br>
&lt;eae> fantasai: The question is how tall is the background painted behind the text, can't set overflow on that element. Has to be set on containing block.<br>
&lt;eae> florian: I'm not an editor for any of these specs, there will be pull requests not in spec.<br>
&lt;eae> florian: Would like to move forward.<br>
&lt;eae> Proposed resolution: Change the wording such that 2.1 is saying you should define the content area based on the first available font and only that font.<br>
&lt;eae> RESOLVED: Change the wording such that 2.1 is saying you should define the content area based on the first available font and only that font.<br>
&lt;eae> &lt;/day><br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1804#issuecomment-342389094 using your GitHub account
Received on Tuesday, 7 November 2017 06:33:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 7 November 2017 06:33:36 UTC