[css-fonts-4] [varfont] Font variations do not support responsive layout

[vlevantovsky]

Font variations have been identified as one of the most desirable features for responsive web design, yet the current implementation only supports static settings for variation axis / value pairs. We need to enable variable variation setting values to make it possible to apply font variations when e.g. a browser window is resized.

[svgeesus]

background:
Variable Fonts for Responsive Design (Nick Sherman)
https://alistapart.com/blog/post/variable-fonts-for-responsive-design

[vlevantovsky]

Also, according to Jason Pamental, variable fonts "may be the most significant development for design on the web since responsive design itself". Let's make them work as intended :)

[litherum]

Do you propose anything more than simply allowing calc() in the properties which set variations? That seems sufficient to me.

[vlevantovsky]

Using calc() may be enough for weight / width variations but I can easily foresee a use case where a variation axis of a font might be e.g. text size dependent (for example, size changes might trigger the variations of stem widths / serif size [similar to optical size design variations], etc.). If the text size itself can be part of the responsive design, we need to make sure that the variations can also be text size-specific.
[I think we need to spend some time thinking through the use cases before we can declare we have a solution that would be sufficient for all use cases.]

[litherum]

Calc with em units will respond to font size.

What are the use cases you have in mind?

[vlevantovsky]

I don't claim to have a complete list of all use cases readily available, I was hoping that other WG experts on responsive design would contribute their views on how responsive layout can affect font variations. Considering that pretty much any aspect of a typeface design can be subjected to variations, I just want to make sure that we'll give it enough attention to not overlook something useful / important.

[litherum]

The stylistic relationship between the UA environment and the specific values chosen for properties (or variation axes) must be chosen by the designer, not the browser. This is how all responsive design works: media queries or environment-dependent units let authors apply some style with regards to the environment, but that style is supplied by the web author. Font variations are part of the reaction to the environment, not the environment itself. Detecting if variations are supported by the browser is already possible with @supports.

That being said, there are only a few (4) variation axes which are well-known (and mentioned in the OpenType spec), and each one has a CSS property associated with it. Browsers can't choose good values for your examples of stem widths and serif sizes because browsers have no concept of those axes (because they are not well-known). If a web author wants to adjust stem widths and serif sizes, they must do it themselves with font-variation-settings and the existing responsive design mechanisms. If a web author wants to adjust one of the four well-known properties, they can do that too using the existing properties.

An example of responsive design working well is with the font-optical-size property, which just accepts two values: auto and none. This lets the browser select the best optical size from the environment in which the text is shown. However, it doesn't make sense for the other 3 well-known axes to accept values like this: no designer wants the browser to control the weight of the type, or whether or not it is italic.

If we add new well-known variation axes, I totally agree that each one should be investigated with responsive design in mind to determine the best way it can be used by authors, browsers, and font creators. I am happy to hear use cases to see if there are any that are not currently solved that are also worth solving.

I guess what I'm trying to say is that the title of this issue, "Font variations do not support responsive layout," is false because font variations provide the same support that every other property does. Maybe one day, when we add a new property, we'll do it badly, but for the support that exists in CSS today, responsive designs are supported the same way they're supported anywhere else.

Of course, I invite any/all designers to discuss use cases where the current CSS support is insufficient (which we are currently doing in the many other open issues).

[vlevantovsky]

... there are only a few (4) variation axes which are well-known ...

It's a common misconception to think that variations in a font are limited to only well known axes of design that may result in changes to weight, width, or optical size, etc. IMO, a [better] generic way to think of font variations is to see them as an arbitrary set of control points with the attached delta vectors grouped together on an arbitrary variation axis that has its own name, range of values, and produces very specific visual results. The "Buffalo Gal" font offers a good illustration of how various variation features can be defined and used outside of what might be considered traditional font family properties such as weight and width variations axes.

You may be right that the original title of this issue is over-reaching since certain cases can certainly be supported as is. My goal (as I once mentioned) was to make sure that the connections between font variations settings and features and needs for responsive design are discussed and well understood before we declare it done.

[vlevantovsky]

Here is another example where variations for responsive layout might come very handy.
The example itself uses interpolation (not a real variation font), but it is a very nice demo of a specific feature where certain properties of a typeface can be made variable, which would result in a controlled transition between low and high contrast designs that are applied within a specific, pre-determined width range. As a default setting, the low-contrast face is rendered when the window width <= 900, and the variation between low-contrast and high-contrast design is applied when the width increases to 1500.
Something like this can e.g. be implemented with the variation axis defined as "contrast" (again, outside of a traditional, well-known set of variation axes).

[vlevantovsky]

In an effort to not let this one drop off the radar screen - what I'd like us to review and confirm is that the current draft of font variation support can satisfy the following (see previous examples) use cases:

1. Responsive layouts, where e.g. changes in window size can immediately be reflected in font variation (weight / width) changes - calc() may be sufficient for this.
2. Responsive layout with border conditions (where e.g. a variation is to be applied only within a range of width values) - media query combined with calc() may be enough to solve this, but I am not sure if the conditions can be nested - e.g. when media query is used to change the layout, such as # of columns, column width, etc., and then we need to determine font variations settings, e.g. based on the applied column width.
3. Ability to enable interactive font variations where controls for certain variation features may be desirable to expose to a user (see Buffalo Gal example, where a number of variation features could be considered as a style choice).

[litherum]

Responsive layouts, where e.g. changes in window size can immediately be reflected in font variation (weight / width) changes - calc() may be sufficient for this.

Yep - calc() and media queries.

Responsive layout with border conditions (where e.g. a variation is to be applied only within a range of width values) - media query combined with calc() may be enough to solve this, but I am not sure if the conditions can be nested - e.g. when media query is used to change the layout, such as # of columns, column width, etc., and then we need to determine font variations settings, e.g. based on the applied column width.

Border conditions can be achieved in calc() with min() and max(), and with media queries with min-width and max-width.

Reacting to parent element width is a problem outside the scope of the Fonts spec. It is difficult because of shrink-wrapping (e.g. the width of a floating element is dependent on its children, so the width of the children can't be dependent on the parent). The current approach is to sidestep this problem and react to viewport sizes rather than element sizes.

Ability to enable interactive font variations where controls for certain variation features may be desirable to expose to a user (see Buffalo Gal example, where a number of variation features could be considered as a style choice).

Once you enter the world of interactivity, script is required. Once script is involved, you can build up any variation values and apply it to the font-variation-settings property.

[litherum]

We were discussing this during this week's F2F, and I think we covered all the aspects of it. If there's nothing else, I'll close this issue. Otherwise, please let us know what new pieces of this need to be discussed.