- From: jfkthame via GitHub <sysbot+gh@w3.org>
- Date: Wed, 23 Sep 2020 13:10:38 +0000
- To: public-css-archive@w3.org
> And it means that either it will be wrong for printed copies of web content (because the 133% scaling isn't applied to printed output) or there'll be a mismatch between screen display and print, potentially resulting in surprising reflows, etc., when a document is printed. I tested this in Safari 13.1 on my MacBook, and confirmed that when printing, it maintains the _same_ `opsz` value as it uses for screen display. So this means it is using the "wrong" optical size setting for the actual printed output. If I print content with the same font, at the same physical size, using Pages.app then I get the "correct" optically-sized glyphs. There's a fundamentally inconsistent set of requirements here. The "cleanest" resolution would probably be to recognize that the Mac browsers are presenting an enlarged-by-default view of content where `opsz` should be set according to the font size in CSS `pt` (*not* `px`, as they currently do), so that printed output (where "physical" units have a clearer meaning than they do on screens) is correct; the screen display would be a _linearly_ scaled-up (_not_ optically resized) view of this. But I'm doubtful we'll get agreement to make that change. It would mean that on-screen text in the browser looks a little different than it does in other applications, because for what looks on screen like the same font size, the browser is actually showing a 133%-scaled view of a smaller optical font size. But it would be consistent with the fact that "12pt" in the browser is displayed at a different size on screen compared to "12pt" in other apps. Failing that -- if the Mac browsers insist on maintaining the `opsz` = CSS `px` setting -- then we have a system where _something_ is necessarily broken; and in that case, it makes sense to provide authors with a way to choose which behavior they want, and which inconsistency they will therefore accept as a trade-off. `font-optical-sizing: none | auto | pt | px` does this pretty reasonably, I think. (The geek in me quite likes the idea of `font-optical-sizing: <number>` as originally proposed here, though I would be inclined to argue that `1.0` should mean that CSS *points* -- rather than pixels -- are equated to `opsz` units, and the default macOS browser behavior would be equivalent to `font-optical-sizing: 1.33333`. But I'm not sure there's really a compelling case for the extra flexibility.) -- GitHub Notification of comment by jfkthame Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4430#issuecomment-697354147 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 23 September 2020 13:10:40 UTC