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

Re: [csswg-drafts] [css-fonts] Proposal to extend CSS font-optical-sizing (#4430)

From: jfkthame via GitHub <sysbot+gh@w3.org>
Date: Tue, 23 Jun 2020 18:19:10 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-648334016-1592936349-sysbot+gh@w3.org>
@svgeesus said in https://github.com/w3c/csswg-drafts/issues/4430#issuecomment-543257559:

> I notice that [the one rendering-based WPT test for optical sizing](https://test.csswg.org/harness/test/css-fonts-4_dev/spec/css-fonts-4/section/8.1/variable-opsz/) checks that the result of
> 
>    1. setting the `font-size` (in px) with the initial value (`auto`) of `font-optical-sizing`
> 
>    2. setting `font-variation-settings: 'opsz'` to the same value as the px value
> 
> 
> matches. In other words, the test checks that `opsz` is set in `px`. So yes [there is interop](https://test.csswg.org/harness/results/css-fonts-4_dev/grouped/section/8.1/) but the rendered result in real-world usage will be suboptimal because the adjustment created by the font designer is not being applied correctly.

but in fact there is *not* as much interop as one might expect, given that according to my testing (see above), Chrome on Windows is using the font size *in device pixels* (not the CSS px value) to set the `opsz` variation. Therefore, its behavior varies depending on the user's display scaling factor; the testcase will fail for users with hi-dpi displays.

The fact that users are not vociferously complaining about this issue (AFAIK) encourages me to believe that we can improve behavior (in ways that may affect existing sites) without undue compatibility risk.

-- 
GitHub Notification of comment by jfkthame
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4430#issuecomment-648334016 using your GitHub account
Received on Tuesday, 23 June 2020 18:19:12 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:09 UTC