I'd propose the value of the font-size parameter, converted to points, would be used for optical style selection

I'm not sure about a font-size value in pt, because 'base' PPI varies, on Microsoft and Web platforms it is 96, while on Apple it is 72.

cc @dberlow

This is incredibly helpful. Thank you so much, @robmck-ms.

Because font-optical-size doesn't actually let web authors set the optical size value directly, I'd imagine this description is most valuable to implementors to figure out what to do when font-optical-size is auto.

I think the best way forward is to summarize this advice and put it into a non-normative section in the fonts spec. @robmck-ms: Is it okay if I put the following text into the spec? (Also please feel free to revise / comment on it)

This section is non-normative.

Selecting a value to supply for the 'opsz' variation axis when the 'font-optical-size' property computes to 'auto' is explicitly not defined here. However, there are some best practices found experimentally for selecting this value.

In an ideal world, the optical size value would select the optical style of a font based strictly on the visual angle that the text subtends as light enters your eye. Unfortunately, visual angle as an input variable to optical style selection breaks down when we try to apply it in the real, digital world.

People have a wide range of visual acuity, even corrected, thus the visual angle you might want to use to transition to a caption style for one person may be very different for another. One could also look at using physical, rendered size on screen, but that too has many problems. In accessibility scenarios, you end up with a floor function in the design of the font, with all text displaying at the optically smallest style, eliminating information about hierarchy and semantic relationship. In projection scenarios, you'd have the reverse - everything displayed in the optically largest style, which not only loses hierarchy, but is inappropriate.

In the end, one approach that could work well would be that optical style is a function of the text size within the document. For example, if the content specifies 10pt type, then that is used to select the optical size, regardless of how big the letters end up in the real world.

So, for HTML/CSS, I'd propose the value of the font-size parameter, converted to points, would be used for optical style selection. For variable fonts, this would be the user coordinate of the optical size (opsz) axis). For static font families, this would be used to select a font based on the STAT table (see #806).

This is also my recommendation.

Given that everyone seems to agree to using font-size, perhaps we should make that part normative. We could say something like "font-size must be taken into consideration when selection a variation value for the 'opsz' axis, but other signals may also be considered." Then, we could test it by making sure that different values of font-size yield different visual results.

Yes, feel free to use this. I agree that we should make the mapping from font-size to opsz more explicit. I worry about "but other signals may also be considered" because type designers won't know those other signals, thus won't know how to design accordingly.

I think it's important to say that this size selection happens before browser zoom or OS scaling.

I think it's important to say that this size selection happens before browser zoom or OS scaling.

It already does, to some extent. It states that only zooms which affect layout may change the selected value for this variation axis. However, I can't define what layout-affecting zoom is because every browser has their own concept of zoom and many of them are subtly different. (And, by that same logic, I also don't want to specify what exactly "layout" is either.)

I don't want to specify the exact algorithm for selecting the variation axis value because this should be a place where browsers are allowed to innovate. But I also do want to help implementers not choose a terrible algorithm. That's the reason for the "This is a good place to start, but feel free to expand beyond it" wording. Perhaps we could put an explanation in non-normative text describing that this value is expected to be "close" to font size. What do you think?

Yep. Safari has at least 4 kinds of zoom.

@dberlow has a good point about selecting opsz after browser zoom. I looked into this. My understanding, though, is that browser zoom is more often used by people with low vision to make text readable than it is for other uses.

For these users, who need to use very large text sizes, selecting opsz after zooming would shift all the text towards display styles, which is exactly the wrong thing for them. For low vision users, it's more helpful to have all the design choices embodied by small and text optical styles as those prioritize legibility. So, selecting opsz before browser zoom is more helpful. This is the motivation behind my accessibility point above. It does mean that typography suffers for those with normal vision, but it also helps people with low vision read better.

We can put this point in the non-normative portion of the spec. I suspect then, those with vision problems will gravitate to those browsers that implement selection before zoom.

I think I've addressed the things this conversation has brought up, so I'll close this bug. Please reopen or let me know if you think the above commit isn't appropriate.