W3C home > Mailing lists > Public > public-css-archive@w3.org > October 2019

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

From: Rob McKaughan via GitHub <sysbot+gh@w3.org>
Date: Tue, 29 Oct 2019 19:35:44 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-547593946-1572377743-sysbot+gh@w3.org>
It seems like there are two issues here:

1) The size that text is rendered
2) What value to set opsz to for a given size

For the first issue, the web community has gone through an enormous amount of work to carefully define units, sizes, etc to get this right, and has done so. E.g. as @litherum describes, on macos and ios, 1 CSS px = 1 CoreText pixel = 1 macos typographic point. That is exactly the right choice to ensure text size rendering across all applications on macos and ios. Similarly folks have analogous choices to maintain text size consistency on other platforms. None of this could or should change.

So we come to the second issue: what is the implementation recommendation for the value to set opsz to for a given text size in CSS, which can be defined in myriad ways, but ultimately comes down to CSS px? Safari's implementation (and FireFox and I believe Chrome following in suit) is to set opsz = px. This recommendation is consistent on macos because opsz is defined in terms of points, and macos typographic points = CSS px. To ensure cross-platform consistency, then other browsers on other platforms would have to follow suit and set opsz=CSS px, even though the assumption this is based on (CSS px = OS point) is not true. 

I've several concerns with this approach:

1) There is no way for a font maker to make a single font that works the same in print as it does on the web. For example, many font makes have customers in the magazine, newspaper and book publishing world (as well as advertising), who care very much that print matches web. With the above recommendation, text at the same nominal size (e.g. 20pt) will look different between web and print. To satisfy their customers, font makers would have to issue two versions of the font - one for print, and one with opsz scaled by 3/4 for the web (and managing two versions of the same font isn't a great compromise for customers, either - especially since one of the selling points of variable fonts is simplifying the number of font files you have to deal with). An alternative implementation is for the W3C to ratify @lorp and @twardoch's proposal so foundries can tell their customers to go always set this property in CSS.

2) If designers don't know to apply the correction to fonts with an opsz axis built as the OpenType specification defines, then it negatively impacts legibility. The font will render with a higher effective opsz, which biases the font away from legibility and towards personality. In reading, legibility is everything.

3) This recommendation does not implement the OpenType specification as the specification was intended. As someone who worked the OpenType spec, I would love for the OpenType world and the CSS world to be able to work smoothly together, the two specifications complimenting each other. It doesn't feel so smooth right now. (But perhaps that's natural as we're all learning each other's context, assumptions, immutables, etc). 

So, here is my proposal: 

First, we must not make any changes to the fundamental assumptions that have already been made for text sizing. Macos will still have 1 CSS px = 1 CT px = 1 macos typo pt, as it should be, and analogously in other platforms. Second, the implementation recommendation would be that browser set the value of opsz to 4/3 of CSS px. As I understand it, the CSS px is the fundamental, common unit, so we relate the recommendation to it and not "point" as it is too varied in definition and implementation (CSS point, macos point, windows point, UK point, European point, ...). 

By doing this, print matches the web; legibility is maintained; and the CSS specification and OpenType specifications are in harmony (as opposed to dissonance we are experiencing in this thread).

Failing that, then we still need some other solution. W3C could adopt @lorp and @twardoch's proposal, as it's a lovely compromise. But, I know I'd have to recommend everyone set font-optical-sizing to 0.75 to make fonts work, and the engineer in me cringes at the idea of having a solution in which everyone sets X to Y to work well. But perhaps there is another solution?


-- 
GitHub Notification of comment by robmck-ms
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4430#issuecomment-547593946 using your GitHub account
Received on Tuesday, 29 October 2019 19:35:45 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:55 UTC