W3C home > Mailing lists > Public > public-css-archive@w3.org > June 2020

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

From: fantasai via GitHub <sysbot+gh@w3.org>
Date: Wed, 10 Jun 2020 04:40:24 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-641716202-1591764023-sysbot+gh@w3.org>
[Minutes of the 2017 Tokyo F2F discussion](https://lists.w3.org/Archives/Public/www-style/2017May/0055.html)
[Minutes of 2017 Paris F2F discussion](https://lists.w3.org/Archives/Public/www-style/2017Sep/0003.html)
[Minutes of 2017 Sept 27 telecon](https://lists.w3.org/Archives/Public/www-style/2017Sep/0054.html)
[Minutes of 2017 SF F2F discussion = resolutions on definitions of line-height calculations](https://lists.w3.org/Archives/Public/www-style/2017Dec/0007.html)

[Meta-bug on line-height issues](https://github.com/w3c/csswg-drafts/issues/1796)

I believe most of this is captured in the current CSS Inline Layout draft in this section, which derives from CSS2.1&sect;10.8: https://drafts.csswg.org/css-inline-3/#inline-height

What wasn't covered there was how the font's own line-gap/line-height metrics are handled. It's clear from the discussion that when they apply, the gap is split in half, and half applied above and half below the baseline. What's not entirely clear to me is if this is done:
- only when computing the height of the line box
- also when establishing the inlineā€™s content edges (for background painting)
- also when aligning by `vertical-align: text-top`

I suspect we only want the first one, so I've gone ahead and made that explicit.

Agenda+ to review this all with the CSSWG.

GitHub Notification of comment by fantasai
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1254#issuecomment-641716202 using your GitHub account
Received on Wednesday, 10 June 2020 04:40:25 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:27:12 UTC