[css-fonts] Proposal to extend CSS font-optical-sizing

[Lorp]

Introduction

This proposal extends the CSS Fonts Module Level 4 font-optical-sizing property by allowing numerical values to express the ratio of CSS px units to the the units used in the opsz OpenType Font Variation axis. The ratio is intended to be multiplied by font-size, measured in px, allowing control over the automatic selection of particular optical size designs in variable fonts.

The proposal resolves the conflicting implementations of the font-optical-sizing: auto behaviour, and provides additional benefits for font makers, CSS authors, and end-users.

Examples

• font-optical-sizing: 1.0; current Apple Safari behaviour where 1px = 1 opsz unit
• font-optical-sizing: 0.75; Apple TrueType and OpenType behaviour where 1px = 0.75 opsz units (1px = 0.75pt in many user agents)
• font-optical-sizing: 0.5; custom behaviour where 2px = 1 opsz unit, to “beef up” the text (e.g. in an accessibility mode for visually impaired end-users)
• font-optical-sizing: 2.0; custom behaviour where 1px = 2 opsz units, to reduce the “beefiness” of the text (suitable for large devices)
• font-optical-sizing: auto; use the font-optical-sizing ratio defined in the user agent stylesheet

Background

OpenType Font Variations in CSS

When the OpenType Font Variations extension of the OpenType spec was being developed in 2015–2016, Adam Twardoch and Behdad Esfahbod proposed the addition of the low-level font-variation-settings property to the CSS Fonts Module Level 4 specification, modeled after font-feature-settings.

For higher-level control of font variations, there was general consensus that the font-weight property would be tied to the wght font axis registered in the OpenType specification, font-stretch would be tied to wdth, while font-style would be tied to ital and slnt.

OpenType opsz variation axis and CSS font-size

The consensus was that the CSS font-size property could be tied to the axis registered for optical size, opsz. The opsz axis provides different designs for different sizes. Commonly, a lower value on the opsz axis yields a design that has wider glyphs and spacing, thicker horizontal strokes and taller x-height. The OpenType spec suggests that “applications may choose to select an optical-size variant automatically based on the text size”, and states: “The scale for the Optical size axis is text size in points”. Apple’s TrueType Variations specification (on which OpenType Font Variations is based) also mentions point size as the scale for interpreting the opsz axis: “'opsz', Optical Size, Specifies the optical point size.” It is notable that neither the OpenType spec nor Apple’s TrueType spec addresses the interpretation of opsz values in environments where the typographic point is not usefully defined.

Optical sizing introduces a new factor in handling text boxes in web documents. If the font size of a text box changes, the proportions of the box not remain constant because of the non-linear scaling of the font; typically the width grows at a slower rate than the height, because of the optical compensations in typeface design mentioned above. Realizing that many web documents may rely on the assumption of linear scaling, Twardoch proposed an additional CSS property font-optical-sizing:

• value auto: “enables” optical sizing by tying the selection of a value on the opsz axis to the font size change
• value none: “disables” optical sizing by untying that selection, so font size change happens linearly

The font-optical-sizing property is currently part of CSS Fonts Module Level 4 working draft.

Controversy: opsz axis and CSS font-size (px vs. pt)

Unfortunately recent browser developments introduced ambiguity in terms of how opsz values should be interpreted:

• Most browser implementers interpret opsz as expressed in CSS pt units (points). If optical sizing is enabled, all text has its opsz axis set to the value of the font size in pt. [In fact, Chrome and Firefox, as well as Safari, interpret opsz in px units. Updated thanks to @drott’s comment below.]

• Apple in Safari has decided to interpret opsz as expressed in CSS px units (pixels). If optical sizing is enabled, all text has its opsz axis set to the value of the font size in px.

• Font makers and typographers are upset at Apple’s decision. They design fonts with the assumption that opsz is expressed in points. Since px values are commonly higher than pt values (typically at a ratio of 4:3) interpreting opsz in px means the that a higher optical size will be chosen than intended. For 9pt/12px text, the opsz design 12 will be chosen, which will yield text that is too thin, too tightly spaced, and potentially illegible. They argue that the user experience will degrade, and optical sizing will actually yield worse results than no optical sizing, effectively defeating the whole purpose and unjustly giving variable fonts bad reputation. Inconsistent behaviour with the same font will cause problems for font makers and CSS authors.

• Apple defends this decision, suggesting that CSS authors can simply set font-variation-settings: 'opsz' n.

• CSS authors object that using font-variation-settings breaks the cascade for font styling and, because of the nature of optical size, is unsuitable for application at the document root level. Therefore it will not get used.

Proposed resolution: numerical values in font-optical-sizing

The CSS font-optical-sizing property currently controls the relationship between font-size and opsz by means of a simple switch (auto/none). We propose to allow a numeric value for font-optical-sizing. This value expresses the ratio of opsz units to CSS px. Examples:

• font-optical-sizing: 1.0; current Apple Safari behaviour where 1px = 1 opsz unit
• font-optical-sizing: 0.75; Apple TrueType and OpenType behaviour where 1px = 0.75 opsz units (1px = 0.75pt in many user agents)
• font-optical-sizing: 0.5; custom behaviour where 2px = 1 opsz unit, which would “beef up” the text (suitable for very small devices)
• font-optical-sizing: 2.0; custom behaviour where 1px = 2 opsz unit, which would “reduce the beefiness” of the text (suitable for large devices)
• font-optical-sizing: auto; use the font-optical-sizing ratio defined in the user agent stylesheet

Results

• User agents can ship with default font-optical-sizing other than 1.0. (The CSS specification might recommend 0.75 as a reasonable default for most situations.)

• Font makers can ship a single font whose opsz axis works as intended in browsers as well as print.

• CSS authors can change the value whenever they like, independently of the choices made by browser vendors and font makers.

• CSS authors can specify a different font-optical-sizing ratio for different media queries, including print, or for aesthetic purposes.

• End-users can be offered accessibility modes that choose low values for font-optical-sizing to ensure lower-than-default opsz values and more legible text.

Note

• This proposal does not introduce breaking changes. We believe that this is one of the rare cases where we can resolve the controversy amicably and provide additional benefits for all parties, while utilizing pre-existing mechanisms.
• Key commits: WebKit Chromium Gecko

Proposers

• Laurence Penney, OpenType Font Variations expert, author of Axis-Praxis.org, member of the MyFonts founding team
• Adam Twardoch, Director of Products at FontLab, contributor to CSS Fonts, OpenType Font Variations and OpenType SVG

[svgeesus]

@Lorp thanks for raising this, and for the detailed and clear write-up.

@litherum it would be interesting to hear the WebKit perspective on this. Was this simply an oversight, so it should be treated as a spec-compliance browser bug, or was this a deliberate decision and if so, what was the rationale?

[drott]

Laurence and Adam, thanks for the proposal and what sounds like a generally reasonable approach to me. However, I have some questions on the Controversy section.

Unfortunately recent browser developments introduced ambiguity in terms of how opsz values should be interpreted:

• Most browser implementers interpret opsz as expressed in CSS pt units (points). If optical sizing is enabled, all text has its opsz axis set to the value of the font size in pt.
• Apple in WebKit has decided to interpret opsz as expressed in CSS px units (pixels). If optical sizing is enabled, all text has its opsz axis set to the value of the font size in px.

Could you clarify for which versions and environments you arrived at this conclusion? When I implemented font-optical-sizing, I found that latest Safari tip of tree uses CSS px (1, 2), and so does Firefox last time I checked (so I disagree with "Most browser implementers interpret opsz as expressed in CSS pt units (points)."). I implemented it based on px in Chrome as well, so I don't think there are any interoperability issues between browsers once the versions I looked at are generally rolled out.

Agree that still, there is potentially and interoperability between say a printing use of a font vs. its use as a web font and there is no affordance for mapping to the intended opsz value.

[davelab6]

The problem is that all browser implementations ignored the OpenType Spec from 2016 and did something different, all in the same way, but we also now have a lot of fonts that were made with opsz axes according to the OpenType Spec.

A CSS px is device pixels per inch / 96, and a CSS pt is device ppi / 72. This is a big deal and imho the default value of this property should be 0.75.

[svgeesus]

And even if we don't end up adding this property, the spec should clarify that opsz is defined to be in pt and thus, browsers using px should use the 0.75 scaling value. I don't see any web-compat downside right now to making that change, because optically scaled type is little used currently and people probably haven't noticed tht it is being set too thin.

[svgeesus]

I notice that the one rendering-based WPT test for optical sizing checks that the result of

1. setting the font-size (in px) with the initial value (auto) of font-optical-sizing
2. setting font-variation-settings: 'opsz' to the same value as the px value

matches. In other words, the test checks that opsz is set in px. So yes there is interop but the rendered result in real-world usage will be suboptimal because the adjustment created by the font designer is not being applied correctly.

[Lorp]

@svgeesus agreed

@davelab6 agreed, with the caveat that your “pixels per inch” should be in quotes, since these pixels are of course based on the visual angle subtended by an idealized median desktop pixel from the year 2000, and thus the physical measure of 1pt in CSS varies significantly between devices/user agents :) But that’s a whole nuther discussion.

@drott thanks for that important correction. As Dave and Chris confirm, the fixed opsz:px ratio value of 1.0 is definitely too high, and even if it were set at 0.75 in all browsers I would resubmit the proposal for the benefits of varying it.

[Crissov]

Minor comment: Why use a float value for font-optical-sizing when CSS usually prefers percentages?

PS: A <length> value would also make sense to specify the size of an opsz unit, where 1px and 1pt would be used in most cases. However, this feels awfully specific to Open Type.

[litherum]

The observation that we made when we implemented optical sizing is that 1 typographic point = 1 CSS pixel.

This is clearly true: Safari, Firefox, Chrome, Pages, Microsoft Word, raw Core Text, and TextEdit all agree. Here is an image of Ahem rendered in all of those using a size of 48 typographic points:

You can see that the rendered size is the same in all of these different apps. In addition, Pages even puts units on the font size: "pt". The documentation for raw Core Text (the second to rightmost app in the above image) also indicates that its size is in points:

The point size for the font

So, when we apply an optical-sizing value of X typographic points, that is equal to CSS pixels, and we apply this correctly.

I'm not making a point (no pun intended) about what should be true, or what the designers of desktop typographic systems intended to be true. Instead, I'm making a point about what is, de facto, true in reality.

[davelab6]

@litherum please could you show us this on windows?

[litherum]

A CSS px is device pixels per inch / 96, and a CSS pt is device ppi / 72.

This is absolutely not true. See #614

[litherum]

@svgeesus

the adjustment created by the font designer is not being applied correctly.

We are absolutely applying it correctly. See #4430 (comment)

[Lorp]

@litherum when you say “typographic point” you seem to be referring to a very Apple-centric measurement, whose dimensions (measured with a ruler off a screen) started off in the 1980s as exactly 1/72 inches, conveniently aligning with early Macs having exactly 72 pixels to the inch. However since then, the size of the Apple 100% zoom screen point has varied significantly depending on the device. At the same time, Apple UIs and documentation continue to refer to this measure as “points” without very often reminding users or developers that each device applies its own scale factor such that these are no longer the 1/72 inch points defined in dictionaries.

As Dave implies, Windows specified its own definition for “standard screen resolution” of 96ppi, and, respecting the idea that a real-world point is 1/72 inches, observed a 4:3 ratio for a font size: in a traditional Windows app, 9 points is 12 actual pixels. Higher device resolutions meant that these pixels became virtual, and that Microsoft, like Apple, could gradually shrink the size of that virtual pixel and, along with it, the physical size of the Windows point.

In CSS, the idea of the “pt” unit is de facto standardized on the Windows relationship of points to pixels, and CSS px are based on the idea of the visual angle subtended by a single pixel on a ~2000-era computer. Thus modern browsers including Safari treat 3pt = 4px.

It was therefore natural that font developers assumed browsers would adopt whatever the user agent defined a CSS pt to be as the scale for the opsz axis.

BTW it is regrettable there is no online reference for what 1px (CSS) measures on modern devices. Here are two classic pt measurements and three data points I just measured with my ruler. In all cases, 1pt (CSS) is 4/3 the size of 1px.

• Macintosh (1984): 0.353mm (1/72 inch)
• Windows points: 0.265mm (1/96 inch)
• MacBook Pro 15" Retina: 0.228mm
• iPhone 5S: 0.152mm
• iPhone 8: 0.152mm