New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
tbrown opened this Issue Sep 26, 2016 · 9 comments

Comments

Projects
None yet
9 participants
@tbrown

tbrown commented Sep 26, 2016

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 comment has been minimized.

Show comment
Hide comment
@litherum

litherum Sep 26, 2016

Contributor

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

Contributor

litherum commented Sep 26, 2016

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

@tiroj

This comment has been minimized.

Show comment
Hide comment
@tiroj

tiroj Sep 27, 2016

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 commented Sep 27, 2016

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

This comment has been minimized.

Show comment
Hide comment
@astearns

astearns Sep 27, 2016

Member
Member

astearns commented Sep 27, 2016

@tbrown

This comment has been minimized.

Show comment
Hide comment
@tbrown

tbrown Sep 27, 2016

@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 commented Sep 27, 2016

@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;

@litherum litherum changed the title from [css-fonts-4] [varfonts] Specify variable font instances relative to an ”anchor point” to [css-fonts-4] [varfont] Specify variable font instances relative to an ”anchor point” Sep 27, 2016

@petrvanblokland

This comment has been minimized.

Show comment
Hide comment
@petrvanblokland

petrvanblokland Sep 27, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@PeterCon

PeterCon Oct 25, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@davelab6

davelab6 Feb 24, 2017

Contributor

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 :)

Contributor

davelab6 commented Feb 24, 2017

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

This comment has been minimized.

Show comment
Hide comment
@xfq

xfq Mar 7, 2018

Contributor

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%);
}
Contributor

xfq commented Mar 7, 2018

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

This comment has been minimized.

Show comment
Hide comment
@xfq

xfq Mar 7, 2018

Contributor

@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

Contributor

xfq commented Mar 7, 2018

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment