[css-fonts-4] [varfont] access to named instances

[gferreira]

Reading the overview here, I miss a way to access pre-defined instances by name. While it's great to be able to choose a value for each parameter numerically, in most common cases it will be easier for font users to choose one among several named instances provided by the type designer.

Here’s an example to illustrate what I mean:

10. Use named, pre-defined variation instances contained in the font

@font-face {
  font-family: "MyVariableFamily";
  src: url("MyVariableFamily.otf");
}

<div style="font-family: MyVariableFamily; font-name: 'SemiBold'>hamburgefonstiv</div>
<div style="font-family: MyVariableFamily; font-name: 'Light Condensed';">hamburgefonstiv</div>
<div style="font-family: MyVariableFamily; font-name: 'Black Extended Rounded'>hamburgefonstiv</div>

note: probably related to this.

[gferreira]

Another syntax idea, similar to font IDs in SVG fonts:

@font-face {
    font-family: "MyVariableFamily";
    src: url("MyVariableFamily.woff#Bold-Condensed");
    font-weight: bold;
    font-stretch: condensed;
}

[robmck-ms]

Relating this back to my STAT table issue #539: It would be helpful to leverage the STAT table to provide names that we can use in font properties.

Context (so we're all on the same page):

• The fvar table in a variable font defines a set of named instances that are equivalent to a font. E.g. "Condensed Bold". These could be used as in both the above proposals
• The STAT table defines a set of named points along each axis. You can think of these as click stops on each axis. E.g. "Normal" and "Condensed" on the width axis, and "Semilight" and "Bold" on the weight axis. This is handy not only for being able to parse names in the fvar table into their components, but for addressing instances (even those that may not be listed as a named instance in the table).

Thus, for a family with weight and width axes, the STAT table might define points for "Light", "Semilight", "Regular", "Semibold", and "Bold" on the weight axis, and "Condensed", "Semi-Condensed", "Normal", "Wide", and "Super Wide" for the width axis. Then, the fvar would define instances as follows:

• "Light Condensed"
• "Semilight Condensed"
• "Condensed"
• ...
• "Bold Super Wide"

Note that fvar need not define all the possible permutations described in STAT, so you may have some interesting instances in the font that aren't listed in fvar.

Ok, so on to my proposal:

1. Allow STAT defined names in standard font properties. E.g.:
   font-weight: "Semi-condensed"; font-stretch: "Super Wide";

2. Allow STAT defined names in the second proposal above. E.g.:
   src: url("MyVariableFamily.woff#Semilight+Ultra-Wide");

or maybe
src: url("MyVariableFamily.woff?wght=Semilight&wdth=Ultra-Wide");

Obviously, if all font designers list all the permutations of STAT in named instances in fvar, then the @font-face src proposal isn't very interesting. The proposal for using names in font properties is the main one I'm interested in.

[jpamental]

I outlined this in #1289 but am copying this over here as an example for how we might be able to do this in CSS:

@font-face {
        font-family: Hamstervar;
        src: url("Hamstervar-VF.ttf");
        font-stretch: normal;
        font-weight: normal,
        font-variation-settings: "wdth" 85, "wght" 327; 
}

@font-face {
        font-family: Hamstervar;
        src: url("Hamstervar-VF.ttf");
        font-weight: bold,
        font-variation-settings: "wght" 572; 
}

@font-face {
        font-family: Hamstervar;
        src: url("Hamstervar-VF.ttf");
        font-stretch: expanded;
        font-weight: bold,
        font-variation-settings: "wdth" 112, "wght" 572; 
}

In this way we tell the browser how to apply the keywords, in this way using font-variation-settings to effectively map the values we want to the keywords expected.

[o-t-w]

There are so many thousands of choices within a variable font and that can be somewhat overwhelming, so named instances are incredibly important. Professional typographers are highly skilled people who will have carefully choose their named instances.

[css-meeting-bot]

The Working Group just discussed Access to named instances in variable fonts, and agreed to the following:

• RESOLVED: "font-named-instance" descriptor in @font-face with values "auto" or "<string>" and in the font-variation-resolution between step 4 and step 5
• RESOLVED: s/auto/none in previous resolution

The full IRC log of that discussion

<fantasai> topic: Access to named instances in variable fonts
<astearns> github: https://github.com//issues/525
<frremy> myles: This is one of the top requests I get from typographers
<frremy> myles: Named instances are how you can associate a string with a position in the variable axises space
<frremy> myles: They want to be able to use them
<frremy> myles: The only way I see would be a property taking that name, and overrides every other property
<frremy> myles: but that isn't great
<frremy> heycam: could we create a shorthand that would override these properties?
<frremy> myles: the problem is that the axes are not always linked to the css axes
<frremy> eae: and the axes might have similar names but be used for things unrelated to what css means
<frremy> chris_: another way for doing that is to add a new descriptor in @font-face
<frremy> florian: does that turn-off all properties that would be used for match
<frremy> florian: we can ignore all the values specified elsewhere
<frremy> heycam: but what if you want to start from a point, the named instance, then tweak one or two axes only?
<fantasai> fantasai: We could pull the named instance, apply CSS modifications on top of it.
<frremy> florian: can we add a new initial value "auto" that is ignored by default but would override named instances otherwise?
<frremy> fantasai: you pick a specific point in the space, and use that as an @font-face directly
<frremy> fantasai: and then you can say what it is even if this is not what the font says it is
<frremy> fantasai: you should be able to do this for axes
<frremy> chris_: the downside is that authors might use the named instances and opt out of the axes
<frremy> chris_: first model is you ask one specific font and use it
<frremy> chris_: second model is the css model, you create families and use properties to change within the families
<florian> q+
<frremy> fantasai: we could also override the named instances axes, like the weight
<fantasai> fantasai: So we pull the named instance, set the various non-standard axes according to the named instance's settings
<fantasai> fantasai: but set the standard axes according to the CSS system
<fantasai> fantasai: which might overide what the named instance would otherwise be, but keeps the CSS system and the font settings aligned
<fantasai> fantasai: E.g. if someone picks out an extra-black instance, but doesn't set it to font-weight: 800, then we apply font-weight: 400.
<astearns> ack myles
<frremy> myles: i think there are two design requirements
<frremy> myles: first is that fonts don't always download
<frremy> myles: content blockers can't for instance drop fonts, so we need to be resilient to font not being downloaded
<fantasai> s/can't/can/
<frremy> myles: second is that the nested cases, where a span needs to be able to bold from its parent
<frremy> myles: we know that because we allow "Arial Bold" for instance as a font family
<frremy> myles: but we do this in a smart way, so if you unbold, you get back Arial
<frremy> chris_: so, we would have the same kind of game in this case, correct?
<frremy> myles: yes
<frremy> chris_: the advantage of having the named instance in the descriptor is that you can use the properties on the child element the normal way
<frremy> chris_: which might be in that font-family or not, but this is the same as css from that point
<astearns> ack florian
<frremy> florian: I'm wondering if we named instances control things that are not css-y, then these values should be controllable by css
<frremy> florian: but does a named instance need a value for all axes?
<frremy> myles: yes, it does have a value for every axis
<frremy> myles: so your proposal is not possible, because there is no default
<frremy> florian: we need a way of saying "this font-descriptor value is for font-matching only" or "this value is a set value, ignore css
<frremy> chris_: basically, this is all because of variable fonts
<frremy> chris_: before we defined a nice set of things and it worked out
<frremy> chris_: but with the ranges we have now, it would create many values
<frremy> florian: if you set a named instance, and don't use descriptor for weight, the range will continue to apply, override the named instance
<myles> q+
<frremy> florian: but if your descriptor is explicitly set, then you would stick to that value
<frremy> florian: for instance "font-weight: <something>" and then you don't use the value from the font instance
<astearns> ack myles
<frremy> myles: in the spec right now, there are many places from which the axes values can come from
<frremy> myles: there is a specific order
<frremy> myles: in this order, descriptor are early, css is after
<frremy> myles: we could say that the named instance applies where exactly it appears in the order
<frremy> myles: then you continue to apply further rules as usual
<chris_> myles summarises the precedence rules from https://drafts.csswg.org/css-fonts-4/#font-feature-variation-resolution
<frremy> myles: my proposal is that we could add a new signal to this algo
<frremy> myles: that would be the named instance
<frremy> myles: and it would be applied very early, other things come after
<frremy> florian: what ordering are you proposing exactly?
<myles> https://drafts.csswg.org/css-fonts-4/#feature-variation-precedence
<chris_> https://drafts.csswg.org/css-fonts-4/#feature-variation-precedence
<frremy> myles: between step 4 and step 5
<frremy> myles: new descriptor that is either auto or string
<frremy> myles: if the value is a string, you look at the font, find that value and apply the axes
<frremy> chris_: I like that
<frremy> eae: that seems nice
<frremy> eae: but if you fallback then these values don't apply
<frremy> eae: you could have one single glyph that uses another font
<frremy> fantasai: but then you have the issue that the axes might not be what css thinks they are
<frremy> myles: it's a little scary if we want to apply the axes of one font file, figure out if you are bold, then use these values in another font
<frremy> myles: if the first font doesn't load, then you get a different result
<frremy> fantasai: yes, i think if you want this, you should also set font-weight bold and that would fallback properly
<frremy> eae: authors might not do that
<frremy> myles: they will need to, because the ordering I propose will have font-weight win over the named instance
<frremy> myles: with this proposal, the named instance will set bold, but the font-weight will override this later
<frremy> fantasai: so the values we use to render are the ones that are in the computed styles
<frremy> florian: and discoverability?
<frremy> florian: better devtools?
<frremy> (general support for myles proposal)
<frremy> PROPOSAL: descriptor in @font-face with values "auto" or "<string>" and in the font-variation-resolution between step 4 and step 5, we lookup the values of the named instance in the font and apply them
<fantasai> frremy: Can we make it alist of names?
<fantasai> frremy: so that way you can handle fallback fonts kindof better
<fantasai> florian: Are you matching the lists? or just go through the whole list per font in src?
<fantasai> myles: We can extend it later to do that, if needed
<frremy> astearns: let's not do this, we can do this later if we want
<frremy> myles: it is backwards compatible to convert this to a list later
<frremy> frremy: ok, sounds good
<frremy> dbaron: but what if you have different font files?
<fantasai> dbaron: What if you want different names per font file in the src list
<frremy> myles: you should only use that for cases when the browsers support different formats
<fantasai> various: No, we don't want to do that
<frremy> myles: not different files
<fantasai> s/use that/use src lists/
<frremy> chris_: myles: let's do this later
<dbaron> dbaron: what if instead of a separate descriptor you have a function that goes in the src: descriptor
<frremy> astearns: if you want that, I think you want that at the "src" level
<frremy> myles: if we want to extend this, we can come up with new ways later
<frremy> (bikeshedding about the name)
<frremy> (font- prefix because all of them have that)
<frremy> (-named-instance because that is what this is called in the spec)
<frremy> chris_: I like font-named-instance, let's use that
<frremy> astearns: so we seem to be converging font-named-instance
<frremy> florian: I'm not going to object
<frremy> RESOLVED: "font-named-instance" descriptor in @font-face with values "auto" or "<string>" and in the font-variation-resolution between step 4 and step 5
<frremy> (one more cycle of the bikeshedding, but the arguments are about the same)
<frremy> fantasai: we can rename things in spec
<frremy> fantasai: but we can chose a better name if we want
<frremy> chris_: yes, but i still prefer what we resolved
<fantasai> s/spec/spec, that's an editorial change/
<frremy> heycam: can we use "none" instead of "auto" though?
<fantasai> s/but we/when we expose terminology through syntax, /
<frremy> RESOLVED: s/auto/none in previous resolution