- From: fantasai via GitHub <sysbot+gh@w3.org>
- Date: Wed, 10 Jun 2020 04:40:24 +0000
- To: public-css-archive@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§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