[css-fonts-4] [varfont] Specify variable font instances relative to an ”anchor point”

[tbrown]

I'm not sure exactly how to point to the spec about this...

I did some thinking on Twitter a few minutes ago:

I say “anchor typeface” to refer to a choice of font (usually body text font) around which you make other decisions (type palette, layout). I’m thinking of saying “anchor point” to refer to a specific point in a variable font’s design space. The point around which it flexes. As a typographer, I might choose the default instance of a variable font (Regular weight/width) as my anchor point — or I might choose a different, unnamed instance. And from there, I would respond to pressure by moving along various axes relative to that anchor point.

By this logic, I might want to specify flexibility and responsiveness relative to the anchor point, instead of picking absolute coordinates in the design space. In the same way that em-based measurements are affected by changing the value to which they all refer, positions along various axes in a variable font would be affected by changing the anchor point to which they refer.

[litherum]

This seems similar to using the "bolder" and "lighter" keywords in font-weight.

[litherum]

This seems similar to using the "bolder" and "lighter" keywords in font-weight.

[tiroj]

As I understand, 'bolder' and 'lighter' simply step up and down through the coarse weight grid, and that should continue to work pretty much as it already does with a variable font weight axis.

I think what Tim is talking about is more like being able to express e.g. size for different levels of text as percentage of body size. If the body type instance of a variable font is taken as the anchor (obviously, it doesn't need to be the body type) then it should be possible to express instances of other type in variable fonts relative to that anchor, such that if the anchor changes, e.g. because a change in device orientation increases the text size and line length, then the other type changes relative to that change.

The tricky thing, it seems to me, is coming up with a way to express design space positions relative to an arbitrary position, since the anchor instance could itself be anywhere in the design space. But I'm no kind of CSS expert nor, for that matter, any good at math.

[tiroj]

As I understand, 'bolder' and 'lighter' simply step up and down through the coarse weight grid, and that should continue to work pretty much as it already does with a variable font weight axis.

I think what Tim is talking about is more like being able to express e.g. size for different levels of text as percentage of body size. If the body type instance of a variable font is taken as the anchor (obviously, it doesn't need to be the body type) then it should be possible to express instances of other type in variable fonts relative to that anchor, such that if the anchor changes, e.g. because a change in device orientation increases the text size and line length, then the other type changes relative to that change.

The tricky thing, it seems to me, is coming up with a way to express design space positions relative to an arbitrary position, since the anchor instance could itself be anywhere in the design space. But I'm no kind of CSS expert nor, for that matter, any good at math.

[astearns]

Could this be done by expressing the anchor as a custom property and the values relative to the anchor as a calc using that custom property's value?

[astearns]

Could this be done by expressing the anchor as a custom property and the values relative to the anchor as a calc using that custom property's value?

[tbrown]

@astearns I don't understand what you mean by “custom property”. Can you tell me more about how that might work?

@litherum I imagine this as more of an exact relativity, like em-based lengths, than lighter/bolder keywords. Not many web designers I know use lighter/bolder, but many people use relative length units.

Related, I had another idea today about snapping to the closest named instance along an axis, perhaps like so:

font-variation-settings: 'wdth' +100 snap;

[tbrown]

@astearns I don't understand what you mean by “custom property”. Can you tell me more about how that might work?

@litherum I imagine this as more of an exact relativity, like em-based lengths, than lighter/bolder keywords. Not many web designers I know use lighter/bolder, but many people use relative length units.

Related, I had another idea today about snapping to the closest named instance along an axis, perhaps like so:

font-variation-settings: 'wdth' +100 snap;

[petrvanblokland]

Making the design and code for the TypeNetwork.com family page we ran into the situation where it would be very useful to have relative axis specification.
An example is here:
https://store.typenetwork.com/foundry/fontbureau/series/benton-sans?family=benton-sans&layout=overview
This is still based on instance font styles of course, but the construction behind the page is already prepared for variations. We now solved the necessary responsive point-sizes by Javascript, but it would be much easier to specify CSS relative to the current value. E.g.

font-weight: +42;
font-width: -85;

adding 42 to whatever the weight is at that moment, and subtracting 85 from the current width axis value. As the "C" in CSS indicates the cascading nature of all values, making them as relative 1.2em is a logical next step.
Apart from the exact CSS syntax, the same would apply for every axis available in the variation font.

Calculation also would be nice, as it could solve legitimate typographic requests like
"bolder by 40% of the distance between the current value and the boldest extreme of the weight axis". This would solve the current problem of not knowing what "bold" means if the "normal" of a text is already selected as "Semibold".

Other use cases:
"make the text fit a specified box width by trying within a -5% to +5% of width axis change, otherwise go back to 100% width axis and make 2 lines" (not to mentioning the need for hyphenation, which brings an entire new typographic issue to the table).

"make automatic small caps by a specific combination of x/y independent scale and x/y independent interpolation" (saving much glyph-data this way, most existing small cap designs can be specified this way. The same applies for superior and inferior numbers). But this needs scaling and interpolation relative to the current font size.

One of the current proposed standard axes is optical size. It is not clear yet how this value connects to the font-size or screen pixels. We cannot trust the OS to decide which [opsz] value to use, because it does not know the viewing distance. And the CSS-developer does not know device-pixels.

[petrvanblokland]

Making the design and code for the TypeNetwork.com family page we ran into the situation where it would be very useful to have relative axis specification.
An example is here:
https://store.typenetwork.com/foundry/fontbureau/series/benton-sans?family=benton-sans&layout=overview
This is still based on instance font styles of course, but the construction behind the page is already prepared for variations. We now solved the necessary responsive point-sizes by Javascript, but it would be much easier to specify CSS relative to the current value. E.g.

font-weight: +42;
font-width: -85;

adding 42 to whatever the weight is at that moment, and subtracting 85 from the current width axis value. As the "C" in CSS indicates the cascading nature of all values, making them as relative 1.2em is a logical next step.
Apart from the exact CSS syntax, the same would apply for every axis available in the variation font.

Calculation also would be nice, as it could solve legitimate typographic requests like
"bolder by 40% of the distance between the current value and the boldest extreme of the weight axis". This would solve the current problem of not knowing what "bold" means if the "normal" of a text is already selected as "Semibold".

Other use cases:
"make the text fit a specified box width by trying within a -5% to +5% of width axis change, otherwise go back to 100% width axis and make 2 lines" (not to mentioning the need for hyphenation, which brings an entire new typographic issue to the table).

"make automatic small caps by a specific combination of x/y independent scale and x/y independent interpolation" (saving much glyph-data this way, most existing small cap designs can be specified this way. The same applies for superior and inferior numbers). But this needs scaling and interpolation relative to the current font size.

One of the current proposed standard axes is optical size. It is not clear yet how this value connects to the font-size or screen pixels. We cannot trust the OS to decide which [opsz] value to use, because it does not know the viewing distance. And the CSS-developer does not know device-pixels.

[PeterCon]

Scenario: I have a reading app in which I want to provide a two-weight contrast (nominally "regular" vs. "bold"), but I want the difference between these to be relative, with the user able to choose lighter or heavier weights along a continuous 'wght' scale of a variable font to suit their preferences.

[PeterCon]

Scenario: I have a reading app in which I want to provide a two-weight contrast (nominally "regular" vs. "bold"), but I want the difference between these to be relative, with the user able to choose lighter or heavier weights along a continuous 'wght' scale of a variable font to suit their preferences.

[davelab6]

The tricky thing, it seems to me, is coming up with a way to express design space positions relative to an arbitrary position, since the anchor instance could itself be anywhere in the design space. But I'm no kind of CSS expert nor, for that matter, any good at math.

Despite being tricky, it seems to me this will be extremely useful for responsive typography :)

[davelab6]

The tricky thing, it seems to me, is coming up with a way to express design space positions relative to an arbitrary position, since the anchor instance could itself be anywhere in the design space. But I'm no kind of CSS expert nor, for that matter, any good at math.

Despite being tricky, it seems to me this will be extremely useful for responsive typography :)

[xfq]

IIUC what @astearns meant might be something like:

:root {
    --font-weight-anchor-point: 400;
    --font-stretch-anchor-point: 75%;
}

.anchor {
    font-weight: var(--font-weight-anchor-point);
    font-stretch: var(--font-stretch-anchor-point);
}

.bold {
    font-weight: calc(var(--font-weight-anchor-point) + 300);
}

.expanded {
    font-stretch: calc(var(--font-stretch-anchor-point) + 50%);
}

[xfq]

IIUC what @astearns meant might be something like:

:root {
    --font-weight-anchor-point: 400;
    --font-stretch-anchor-point: 75%;
}

.anchor {
    font-weight: var(--font-weight-anchor-point);
    font-stretch: var(--font-stretch-anchor-point);
}

.bold {
    font-weight: calc(var(--font-weight-anchor-point) + 300);
}

.expanded {
    font-stretch: calc(var(--font-stretch-anchor-point) + 50%);
}

[xfq]

@tbrown re “custom properties”, they're definitions of cascading variables in CSS: --blah-blah: value.

See this link for an introduction: https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_variables

[xfq]

@tbrown re “custom properties”, they're definitions of cascading variables in CSS: --blah-blah: value.

See this link for an introduction: https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_variables