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

Re: [csswg-drafts] [css21][css-inline] behavior differences when the primary font does not contain U+0020

From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
Date: Tue, 12 Sep 2017 00:41:24 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-328697741-1505176875-sysbot+gh@w3.org>
Further follow up: if U+0020 is missing from the primary font **and** no glyph from the primary font are used, then:
* Related to #1804, Edge is the only browser that continues to determine the height of the content area of inline boxes using metrics of the primary font (current safari does too, but nightly safari does not). See [this test that has U+0020 in the primary font](https://rawgit.com/frivoal/web-platform-tests/line-height-experiments/css/css-line-height/content-height-005.html) to [that one that doesn't](https://rawgit.com/frivoal/web-platform-tests/line-height-experiments/css/css-line-height/content-height-007.html)
* Related to #1801, Firefox joins Chrome, and the position of the baseline in a line-box with a non-normal line-height stops depending on the primary font (and continues not to depend on any fallback font either). Safari and Edge continue to use the primary font metrics. See [this test that has U+0020 in the primary font](https://rawgit.com/frivoal/web-platform-tests/line-height-experiments/css/css-line-height/line-height-003.html) to [that one that doesn't](https://rawgit.com/frivoal/web-platform-tests/line-height-experiments/css/css-line-height/line-height-0014.html)

-- 
GitHub Notification of comment by frivoal
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1798#issuecomment-328697741 using your GitHub account
Received on Tuesday, 12 September 2017 00:41:19 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:26:42 UTC