W3C home > Mailing lists > Public > public-css-archive@w3.org > May 2021

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

From: Laurence Penney via GitHub <sysbot+gh@w3.org>
Date: Thu, 13 May 2021 01:02:22 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-840207323-1620867740-sysbot+gh@w3.org>
I submit that, with the improvements from @fantasai and @jfkthame, we can assemble a proposal that:
* supports direct selection of opsz value
* supports relative selection of opsz value
* supports calc for opsz value
* supports inheritance in an intuitive way
* allows browsers to determine opsz via px or pt units
* is clear and powerful for authors
* does not break current behaviour
* does not constrain browsers’ default to current behaviour
* should proceed

Recall that @fantasai’s [suggestion](https://github.com/w3c/csswg-drafts/issues/4430#issuecomment-693545469) to add `pt` and `px` keywords identifies the unit to be used for matching font-size to opsz.

Recall @jfkthame’s [suggestion](https://github.com/w3c/csswg-drafts/issues/4430#issuecomment-771861705) to specify a length rather than a number. Lengths will typically be in `px`, `pt` or `em` units. Consider an element having `font-size: 18px;`, for which we wish to use an optical size 0.5× the automatic selection. One possibility is `font-optical-sizing: 9px;`. But we could also use `font-optical-sizing: 0.5em;`. The latter method has the great advantage of inheritance in `em` — child elements will also use a 0.5 factor in their own opsz determinations. Setting `font-optical-sizing: 0.5em;` at the root level thus causes all fonts to adjust their opsz proportionately, whatever their font-size, which is quite a desirable effect. As @jfkthame points out we can also use `calc` for lengths, such as `calc(1em - 2pt)` (unlike a unitless number), so @tiroj’s [example](https://github.com/w3c/csswg-drafts/issues/4430#issuecomment-771845138) of +2 and -2 opsz units is possible.

By combining the two suggestions we have a way of selecting a particular opsz axis setting: `font-optical-sizing: 9px px;` will select 9 on the opsz axis. This is identical in effect to `font-optical-sizing: 9pt pt;`. Repetition of the unit is inelegant, perhaps suggesting unitless numbers be allowed as simple opsz axis settings, thus `font-optical-sizing: 9;` would be shorthand for the prevous two examples.

Here is a list of examples:

font-optical-sizing: 14pt; /* use whatever opsz the browser wants to use for 14pt text */
font-optical-sizing: 14px; /* use whatever opsz the browser wants to use for 14px text */
font-optical-sizing: 14pt pt; /* use 14 opsz */
font-optical-sizing: 14px px; /* use 14 opsz */
font-optical-sizing: 14; /* use 14 opsz */
font-optical-sizing: pt; /* use pt as the unit for matching font-size to opsz */
font-optical-sizing: px; /* use px as the unit for matching font-size to opsz */
font-optical-sizing: 0.5em; /* use 0.5× whatever opsz the browser would have chosen for this font-size */
font-optical-sizing: 2em; /* use 2× whatever opsz the browser would have chosen for this font-size */

It may be useful to allow the two components of the value to be specified separately:

font-optical-sizing-length: <length> | <number>;
font-optical-sizing-unit: auto | px | pt;

Note that without the `px` and `pt` keyword, `font-optical-sizing-unit` reverts to `auto`.

What we have not done above is to specify what the browser default behaviour `font-optical-sizing: auto;` should be. **I suggest it is unnecessary to do so for this proposal to advance.** Using this proposal, current Apple browser defaults are AFAIK:

font-optical-sizing: 1.0em px; /* for screen media (led by Safari, followed by others) */
font-optical-sizing: 1.0em pt; /* for print media */

GitHub Notification of comment by Lorp
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4430#issuecomment-840207323 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 13 May 2021 01:02:24 UTC

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