- From: jfkthame via GitHub <sysbot+gh@w3.org>
- Date: Tue, 23 Jun 2020 15:43:23 +0000
- To: public-css-archive@w3.org
FWIW, I measured that "50mm" square on both the displays I have on my MacBook (the built-in panel and an external hi-dpi Dell display), with both at their "default" settings (though I usually run with adjusted scale factors). At the default scale, it measures 36mm on the laptop screen, and 58mm on the external. But all the browsers I've tried treat both displays identically for the purpose of auto-opsz setting; they don't make adjustments to the text when I drag a window from one to the other, despite the physical size changing by a factor of 1.6. (And this is how it should be, IMO: I would find it extremely annoying if moving window between these displays resulted in optical sizing changes and hence text reflow.) Using the example at https://jfkthame.github.io/test/optical-sizing/amstel.html, I can see that all the browsers use the `font-size` in CSS `px` as the value for auto `opsz` setting. As noted above, I think this is wrong; it would be more correct to use the value of the `font-size` in CSS `pt` units, i.e. the 0.75 × the `px` value, as this is intended ( Where the browsers (on macOS) differ is in their handling of zoom: if I zoom the above testcase, I see that Firefox keeps the optical sizing constant regardless of zoom level, always being based on the CSS `font-size`, whereas Chrome and Safari adjust for the zoom scaling, so that at 75% page zoom (but only at that scale), the auto optical sizing matches the `font-size` as expressed in `pt`. On my ThinkPad running Windows 10, it's a different story. Again, I have two screens, a hi-dpi laptop screen where the "50mm" square measures 45mm, and a lo-dpi external display where it measures 48.5mm. (So it's fairly close to "accurate" on both displays.) Loading https://jfkthame.github.io/test/optical-sizing/amstel.html in Firefox, I see the same result as on macOS: the result of auto optical sizing corresponds to setting the `opsz` axis to the CSS `font-size` in `px` units, and stays constant when the window is moved between screens. But in Chrome, the result is quite unexpected: if I load https://jfkthame.github.io/test/optical-sizing/amstel.html on the internal (hi-dpi) laptop screen, the auto optical sizing is giving me unexpectedly "thin" glyphs (large optical size); it only reaches the point where the auto rendering matches setting `opsz` explicitly to the CSS `font-size` if I zoom all the way out to 50%. (So it is using the page-zoom scale factor, like it does on macOS, but with a different starting point.) However, if I move the window to the (lo-dpi) external screen, it matches Firefox's rendering at 100%. My conclusion here is that Blink on Windows is using the font size *in device pixels* as the basis for automatic optical sizing (and hence the need to zoom out to 50% on the hi-dpi screen to get the expected result). This is surely wrong. Given the general lack of consistency/interoperability here, and the fact that there's probably not a huge amount of web content currently depending on fonts with automatic optical sizing, I do think there's an opportunity to fix things. Comparing font sizes in the web browsers to font sizes in desktop applications such as word processors, it does appear that on macOS (as @litherum has pointed out), everyone has implemented things such that 1 CSS px = 1 Cocoa pixel = 1 typographic point (nominally, subject to actual display scale etc), so a font specified as `72px` in CSS in the browser will match one specified as `72pt` in a desktop word processor. I think this is unfortunate, as it means that (confusingly) `72pt` in CSS does *not* appear the same as `72pt` on the desktop, but that ship sailed long ago, I fear. So on macOS, for automatic optical sizing to work the same in the browser as it does in native desktop apps, it should indeed be based on the CSS font size *in `px` units* (contrary to what I argued for above). On Windows, OTOH, a font size specified as `72px` in CSS appears significantly smaller than a font size of `72pt` in a desktop word processor; indeed (as expected) I have to zoom the browser page to 133% for them to look the same. At 100% zoom in the browser, `72pt` in CSS *does* appear the same as `72pt` in a desktop app. So in this environment, the correct basis for automatic optical sizing should be the CSS font size *converted to `pt` units*. I don't like this result; I think the same page, using the same font resources, displayed on similarly-sized screens on macOS and Windows ought to look essentially the same, and it won't if they're using these different factors to apply optical sizing. But I think -- at least for today! -- I've come round to accepting this incompatibility as the lesser of the various evils available. -- GitHub Notification of comment by jfkthame Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4430#issuecomment-648247330 using your GitHub account
Received on Tuesday, 23 June 2020 15:43:34 UTC