[css-fonts-5] [varfont] May want different properties for font matching and variation value

[upsuper]

Before we have variable fonts, font-weight property is only used for font matching, and thus authors can map a weight to whatever font face they want regardless of the designed weight of the font.

However, with variable fonts, font-weight property is now used for both font matching and choosing value for variation, which means authors lose the ability describe above.

I suppose this applies to other properties involving font matching as well, e.g. font-style, font-stretch.

(I'm not sure whether it is an important issue, though, since I'm not a typical frontend developer or designer.)

cc @litherum @nattokirai

[frivoal]

I agree this is an issue. One example of a situation where this is a problem is when an author wants to use multiple fonts with different unicode coverage. The weights at which the fonts are visually a good match is not necessarily when the numeric value of font weight is the same.

With traditional fonts pairing font faces that match visually, and mapping them onto the same font weight number for usage in the stylesheet is easy.

Regardless of the syntax we end up with, we need to the same ability for variable fonts.

[Crissov]

@upsuper means authors can get creative with the font-weight descriptor currently. I don’t see how it affects the property of the same name.

[frivoal]

This comment of mine in #521 (comment) relates to this issue.

[litherum]

Can't font-variation-settings be used to set the rendering variation value as distinct from the one used for font selection? The specific axis names are listed explicitly in the spec for each font-selection property.

[frivoal]

I don't see how that would work, you cannot set different values of font-variation-settings for different font faces.

It seems to me that we need a level of indirection, similar to how you can do

@font-face {
  font-family: foo;
  font-weight: 700;
  src: url('..../foo-700.otf');
}
@font-face {
  font-family: bar;
  font-weight: 700;
  src: url('..../bar-900.otf');
}
.something {
  font-family: foo, bar;
}

Maybe you're using the font stack to deal with the fact that one font may be missing, or maybe you're using it due to different unicode coverage. Either way, you want to use bar-900.otf when the font-weight property is 700. There's a mismatch between 700 and 900, and it is intentional, because these numbers are on an arbitrary scale, so when you want to pair two fonts, you need to set up your own scale and place these two fonts somewhere on it.

How do we do the same with font variations? With the current syntax and semantics, you cannot:

@font-face {
  font-family: foo;
  font-weight: 500-700; /*use when the font-weight property is between 500 and 700*/
  src: url('..../foo.otf'); /* I'd like to use the 500-700 range of that font
                               when rendering, so all is good*/
}
@font-face {
  font-family: bar;
  font-weight: 500-700; /*use when the font-weight property is between 500 and 700*/
  src: url('..../bar.otf'); /* I'd like to use the 700-900 range of that font
                               when rendering because it is otherwise comparatively
                               lighter than font foo, but I cannot express it.*/
}
.something {
  font-family: foo, bar;
}

I suggest we enable something along these lines:

@font-face {
  font-family: foo;
  font-weight: 500-700;
  src: url('..../foo.otf');

  /* the above is the same as font-weight: 500-700 / 500-700; */
}
@font-face {
  font-family: bar;
  font-weight: 500-700 / 700-900;
  src: url('..../bar.otf');

  /* use when the font-weight property is between 500 and 700,
     but render it in with the 700-900 range,
     mapping values from one range to the other linearly */
}
.something {
  font-family: foo, bar;
}

(If you don't like slashes, we can have commas, keywords, or whatever, that's not the point)

You cannot do that with font-variation-settings (or any other property that does not distinguish between font faces), because you need different values per font-face on the same element.

[Crissov]

font-weight-adjust 😜

[frivoal]

font-weight-adjust 😜

Last person I know to propose this was me, and I was proven wrong :)
https://lists.w3.org/Archives/Public/www-style/2015Oct/0151.html

[css-meeting-bot]

The Working Group just discussed May want different properties for font matching and variation value, and agreed to the following:

• RESOLVED: defer this issue to next level

The full IRC log of that discussion

<dael> Topic: May want different properties for font matching and variation value
<dael> github: https://github.com//issues/528
<dael> myles: Right now for font variations the properties are partioned. Set A effects font selection and set B doesn't. A is font-weight, -style-stretch.
<dael> myles: You use value of those to find a font and if it has range of values the requested width or slope is applied
<dael> myles: For those properties they both are used to choose fonts and then they select a point in design space. Issue asks how to separate concepts. I want to select a font-weight but not have it effect font selected.
<dael> myles: There is a way, you can use font-weight properties to do font-selection and after that you can use font-varaition settings of wght and that separates the values. It's not very clean, but it will work the way you want. It's just not as nice
<dael> fantasai: If don't that then...If you had a variable font and you jsut want to use for all weights on page and you're using 3 weights then you would have to crea te a ne @font-face rule for each weight that's pegged to that value and map that to a value on the variation axis
<dael> fantasai: That would work if you had fixed # of weights and you knew what you would use.
<dael> fantasai: If you were animating weight that won't work b/c you have no mapping for intermediate values
<dael> myles: font-face descriptor allows range
<dael> fantasai: Font variations doesn't. So fi you have a font-weight descriptor that's 400-800and then set font variation settings as a default of 500 then you've said this font which is gonna be rendered at 500 always is the 400-800 range. If I ask for the 400 I get the 500 because it wins, right?
<dael> myles: right
<dael> fantasai: You can't create the mapping...you can do it for a single point but not a range
<dael> florian: I think a use case would help
<dael> florian: I think a typical thing is you're using your main font for lots of things, but for & you want a different font. Non-variable you use unicode range to subset and you decide that it looks good at a different size. With @font-face you can do that. With variable you try and do the same thing where the & font is about 200 more then main font you can't do that. You can lock it for specific values, but not on range
<dael> florian: I think we want in the @font-face rule you can map a range to another range. At font-selection if there's a font between 500-700 I'm good and it corrisponds to 700-900. Or something along those lines
<dael> fantasai: Agree that's what needed to solve. Have a similar issue as related to size. It's a bit easier b/c it's constant.
<dael> florian: I thinkt he problem isn't too bad b/c you can slice per linear range you can do it if you have mapping
<dael> fantasai: I think we should solve this, but defer to next level. not super critical, but we do need to...people are shipping. We should get set of features to ship and get the spec to CR. I agree it's a problem and we should look to solve
<dael> myles: I'd like to hear from designers about the problems they're trying to solve
<dael> fantasai: And defer would give time for that to happen
<dael> Rossen: myles okay to defer or did you want to hear now?
<dael> myles: defer is fine
<dael> florian: Okay to defer
<dael> Rossen: Objections to defer this issue to next level?
<dael> RESOLVED: defer this issue to next level

[davelab6]

RESOLVED: defer this issue to next level

When will css level 5 discussions begin? :)

[svgeesus]

When will css level 5 discussions begin? :)

When most of CSS Fonts 4 is implemented in a couple of browsers, and it makes sense to start up a new level with any deferred features plus new ones so that level 4 can be stabilized.

[davelab6]

When most of CSS Fonts 4 is implemented in a couple of browsers

How is that faring? Is there any place to easily check the status of that? :)