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: Mon, 22 Jun 2020 22:22:39 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-647798843-1592864557-sysbot+gh@w3.org>
I don't think this is particularly useful or necessary. Browsers (and CSS in the context of browsers) just don't work like that. Absolute physical sizes made sense in a world of printed paper, but on the Web they're just not that important, nor are they reliably knowable.

Given a font with an `opsz` variation axis, a value like `opsz=6` should be suitable for displaying text that's about the smallest that the viewer can reasonably read; `opsz=72` should be suitable for huge titles; `opsz=12` should be reasonable for the bulk of body text, and so on. But outside of the world of printed paper [intended to be held and read by an individual; things like billboards are different], this doesn't really have any fixed relation to physical sizes. A "body text" size for which `opsz=12` is suitable might be 3mm high on a high-res phone screen, or it might be several inches high when projected on a conference-room screen. But either way, if the text is styled with `font-size: 12pt` in CSS, it should use the `opsz=12` variation setting to produce rendering that's appropriate for comfortably reading small body text.

IMO the `opsz` value applied by `font-optical-sizing: auto` should be directly related to the CSS `font-size`, and the UA should *not* attempt to adjust for the physical size of the output, which in general it cannot know (and may not even be a single unique value -- consider mirrored displays of different physical sizes). This should be true no matter what kind of scaling is in effect to alter the mapping from CSS `px` to physical size: it might be OS-level resolution settings, it might be distance from a projection screen, it might be a page zoom factor, it might be CSS `transform: scale(...)`, etc. No matter; `opsz` is simply based on `font-size`.

The key question here, really, is whether the `opsz` axis should be set according to CSS `px` units or `pt` units. That's a decision that I think the CSS WG needs to consider and specify once and for all.

The most "correct" answer, AFAICS, should be that auto `opsz` = CSS `font-size` in `pt`, but it seems browsers are currently shipping with `opsz` = `font-size` in `px`. I think this is a mistake, and we should fix it; the compatibility impact of doing so will be minor, as per https://github.com/w3c/csswg-drafts/issues/4430#issuecomment-543188228.

Maybe we should also extend `font-optical-sizing` as originally proposed here, to let the author (or UA, or reader) modify the `font-size`-to-`opsz` factor. This seems a reasonable and workable idea, though it's unclear to me how much of a use-case there is for it.

GitHub Notification of comment by jfkthame
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4430#issuecomment-647798843 using your GitHub account
Received on Monday, 22 June 2020 22:22:41 UTC

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