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

> The issue here isn't just of consistency in implementation — of getting the same opsz instance for the same _nominal_ type size in different platforms —, but getting the opsz instance that the type designer has created for an _actual_ size. Otherwise there's no point in calling this optical.

I think that's the opposing position to the one @lorp staked out today, which boils down to that the "actual" size ship sailed a long time ago, and attempting to fix that is way out of reach for us bunch of nerds ;) And in fact, it's gone with good reason - the design ideology of CSS is device independence and easy end user overrides, and users can set their "100% zoom" to 120% or whatever and there's no way to know. 

The CSS pixel isn't a physical unit, but it's the anchor for all other CSS units, including CSS points, so it's the best unit for the web. 

I think of the MS opsz definition has said the opsz values are CSS px units, this issue's proposal would still exist.

So! Fixing the OT Spec is urgent, because more and more opsz fonts are becoming widely available, and the entrenchment of the problem is only going to get worse. 

And today I experienced exactly that falling feeling on this topic, as I read that Apple San Francisco is finally available as an opsz VF:

https://web.dev/more-variable-font-options-in-chromium-83/

I was surprised to see that there are just 2 masters, not set up with a continuous range, as in Amstelvar or Roboto Flex, but as a step function at a break point, like Sitka. However, this offers the "Compress" benefit with backwards compatibility to the pre VF fonts, so fair enough. 

All of Amstelvar, Roboto Flex, and San Francisco are using the GRAD axis tag, but SF is using a completely different set of min/default/max range or scale values. As a "custom" axis outside of the 5 in the OT spec, this is from one point of view fine, but given the extensive documentation about why @dberlow has GRAD the way it is in the former 2 fonts, it seems to me like it might be a missed opportunity to build momentum towards seeing a Grade axis be included in the OT spec. 

I'm perfectly happy to advocate for all opsz fonts to include a OPPT axis, but this risks the same kind of calamity as we now see with GRAD. 

I hope we can come into consensus on how to resolve this issue :)

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

Received on Friday, 22 May 2020 03:11:41 UTC