[css-fonts-4] [varfont] @font-face descriptors should accept ranges

[litherum]

Migrated on behalf of @AmeliaBR

Would there be a value in allowing the font-face descriptors (e.g., font-weight, font-stretch) to take two values, defining the range available from the file?

If you use range descriptors, then the non-variable fallbacks no longer match the descriptors, and would need separate font-face rules. However, I'm pretty sure that still works with @font-face as currently defined, just need to watch the ordering:

@font-face { /* fallback normal weight face */
font-family: BodyText;
font-weight: normal;
src: url(something) format(woff);
}
@font-face { /* fallback bold weight face */
font-family: BodyText;
font-weight: bold;
src: url(something-bold) format(woff);
}
@font-face { /* variable weight font */
font-family: BodyText;
font-weight: 200/700; /* min and max weights */
src: url(something-variable) format(woff2-variations);
}

So user agents that recognize the range descriptor and variable-font format would download the final file, others would download one or all of the backups (depending on which weights are required).

EDIT: I initially had the range descriptor using comma to separate the values. But it would probably be best to reserve commas for a list of distinct values (not a range). So, for example, if a user agent supported OpenType collection files (multiple distinct faces in one file), that could be font-weight: 300, 500, 800, while a variable-weight font with a continuous range would be font-weight: 200/800.

[litherum]

Migrated on behalf of @nattokirai:

Would there be a value in allowing the font-face descriptors (e.g.,
font-weight, font-stretch) to take two values, defining the range
available from the file?

Yes, that's another possibility and others have suggested this for @font-face font descriptor values. It would make the font matching algorithm a bit more complex and I was hoping to avoid making it any more complex than it already is.

My hunch is that with variable fonts we don't need to make the font descriptor syntax more complex. Once all user agents support variable fonts the set of @font-face rules will boil down to one or two rules per family. All the variations will be defined within the font itself. The @font-face would just look something like:

@font-face {
  font-family: BodyText;
  src: url(something-variable);
  /* no need to define additional descriptors for a variable font */
}

[litherum]

If we do go with a range solution, I recommend using syntax similar to unicode-range (so it would use hyphens).

[litherum]

Migrated on behalf of @nattokirai:

Jonathan Kew has also suggested using ranges in @font-face rules:

/* For legacy UAs that don't support variation fonts,
   load individual faces. */
@font-face {
  font-family: BodyText;
  src: url(fonts/BodyText-Regular.otf) format("opentype");
}
@font-face {
  font-family: BodyText;
  font-weight: bold;
  src: url(fonts/BodyText-Bold.otf) format("opentype");
}
@font-face {
  font-family: BodyText;
  font-style: italic;
  src: url(fonts/BodyText-Italic.otf) format("opentype");
}
@font-face {
  font-family: BodyText;
  font-style: italic;
  font-weight: bold;
  src: url(fonts/BodyText-BoldItalic.otf) format("opentype");
}

/* For UAs with variation support: the style and weight descriptors
   cover a range, which means this will override all the preceding
   rules that fall within the ranges. UAs that don't recognize the
   "opentype-variation" support will not load anything here, so will
   fall back to the individual faces above. */
@font-face {
  font-family: BodyText;
  font-style: normal, italic;
  font-weight: 1-1000;
  src: url(fonts/BodyText-Var.otf) format("opentype-variation");
}

So font-stretch would use a percentage range? 50-150%? Hmmm.

[bramstein]

I'm not opposed to this proposal, but I just wanted to point out that adding ranges would likely require web font services to supply default values for the variation fonts they serve, or for web authors to have a syntax so they can "extend" the @font-face rules defined by services.

[litherum]

@bramstein Can you explain a little more? Which scenario would call for a web font service to supply a default value?

[svgeesus]

@bramstein I agree, but those ranges are discoverable from the fonts, and providing them in the stylesheets making up a kit would provide added value to customers of those font services.

[litherum]

I think it's worth mentioning that there is no current proposal to make anything in the @font-face block define which point along any variation axis is actually used. All current proposals describe that style applied to elements defines which point is used, and the descriptors in @font-face blocks are only there for font selection.

[frivoal]

I think it's worth mentioning that there is no current proposal to make anything in the @font-face block define which point along any variation axis is actually used. All current proposals describe that style applied to elements defines which point is used, and the descriptors in @font-face blocks are only there for font selection.

@litherum going slightly off topic, but this actually seems to be an issue, especially if you're mixing several variable fonts, or variable fonts with non variable ones. Since all these axes are on arbitrary scales (and even worse, custom axises of the same name might not even have the same meaning in different fonts), just assuming that the same value on the same axis will make different fonts match each other nicely seems wrong.

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

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

For sure, good syntax to deal with that is not obvious with variable fonts, but losing this ability sounds bad.

Now, mixing the idea of providing:

• ranges in which the variable font should be used
• mapping values on the variable axis to different values in the stylesheet
  how about something like this:
• @font-face { /*...*/ font-weight: 200 600, 900;} => Select this variable font when the stylesheet calls for a weight between 200 and 600 or of 900.
• @font-face { /*...*/ font-weight: 900/753; } => Select this variable font when the stylesheet calls for a weight of 900, and rendering using a weight of 753
• @font-face { /*...*/ font-weight: 200/300 600/650, 900/753;} => Select this variable font when the stylesheet calls for a weight between 200 and 600 or of 900. Map (linearly) the 200-600 range from the stylesheet to 300-650 in the font, and 900 to 753.

Note: this is relates to #528

[litherum]

@frivoal This proposed syntax (with the commas and the slashes) seems much too complicated. All the existing variation fonts I know of simply support a single range of values for each axis, and that is the expectation of all future fonts. It doesn't seem like there is any use case of supporting any sequences more complicated for that. As for the distinction of font selection values from rendering values, we are discussing that in #528.

When considering the concept of a range in @font-face blocks, many content authors may not know the exact algorithm for font selection. Forcing them to write only a single value will likely require them to know details of the font selection algorithm is in order to correctly choose that value (sometimes it is the minimum of the font's available range, and sometimes it is the maximum). Letting the @font-face descriptors match the font's external interface will definitely be helpful for content authors.

[litherum]

Incorporated at 2bf006e