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
Comments
This seems similar to using the "bolder" and "lighter" keywords in font-weight. |
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. |
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 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:
|
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. font-weight: +42; 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. Calculation also would be nice, as it could solve legitimate typographic requests like Other use cases: "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. |
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. |
Despite being tricky, it seems to me this will be extremely useful for responsive typography :) |
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%);
} |
@tbrown re “custom properties”, they're definitions of cascading variables in CSS: See this link for an introduction: https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_variables |
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.
The text was updated successfully, but these errors were encountered: