[css-fonts-4] [varfont] Supported variation font axes and font features are not discoverable

[litherum]

Web authors have requested the ability to know which variation axes and font features are available in the fonts on the page.

[Crissov]

This is clearly out of scope for CSS (although I know next to nothing about CSSOM and Houdini).

Additional or changed descriptors for @font-face would be a different thing. Authors wouldn’t know about available features, but declare what to do if they exist.

[litherum]

Using a media query for this wouldn't work because media queries have no concept of a specific font face to investigate. Instead, it seems that such a mechanism would have to be in JavaScript.

The canvas text metrics API and the forthcoming Houdini text metrics API expose some other font-driven information. However, these APIs give you information about a line (or lines) of text, and would include things like fallback fonts. Variation axes and features are font-specific, so including fallback fonts isn't the right level of abstraction for solving this problem.

A natural place to put this would be to build off of the CSS Font Loading API. This API already has the concept of an object which represents a font face. In addition, a FontFace even already has a "status" enum property which has a relationship to a specific url() inside the FontFace (so there is precedent for this idea already). Maybe a function can be added to FontFace which returns a new object which has a bunch of properties including font info. Calling the function on an in-flight download would result in an exception or something.

Any thoughts? @tabatkins @bramstein @nattokirai @SergeyMalkin @drott @heycam

P.S. According to caniuse, Edge hasn't implemented the CSS Font Loading API, so they would probably have to implement at least some of it in order to go with this proposal.

[svgeesus]

I agree that extending Font Loading API seems like a natural way to get this discoverability. Although it would be nice to be able to code up a test page in HTML/CSS to explore what some font provides.
Ultimately fonts need to have better documentation.

[litherum]

We probably would want something similar for font color palettes.

[svgeesus]

The canvas text metrics API and the forthcoming Houdini text metrics API expose some other font-driven information. However, these APIs give you information about a line (or lines) of text, and would include things like fallback fonts.

Yes. At the early Houdini meetings the assumption was that Houdini would produce a font metrics API, to query features of a particular font (and with the advent of variation fonts, a particular instance). However, over time that was seen as less important for pollyfiller-writers than metrics on fonts used together in a text segment, which eventually became the text metrics API.

There is still a need to query an individual font instance.

[briansmith]

Consider the following CSS:

@supports (font-feature-settings: "subs" 1) {
  sub, sup { vertical-align: baseline; font-size: 100% }
  sub { 
    font-feature-settings: "subs" 1
  }
  sup {
    font-feature-settings: "sups" 1
  }
}

Basically, I want to use have the font position/size the superscripts and subscripts if it supports those features. Otherwise, I want to use the default positioning/sizing. However, this doesn't work, because the browser does support font-feature-settings: "sups" 1 but the font itself is missing the feature.

[tabatkins]

Right. Thus the earlier conclusion of "this belongs in JS, probably attached to the FontFace API defined in Font Loading".

[briansmith]

Right. Thus the earlier conclusion of "this belongs in JS, probably attached to the FontFace API defined in Font Loading".

Why should one have to write JS for these things? I don't think one should. And why should one have to use the font loading API if they aren't even loading any fonts, but instead using only the browsers preloaded fonts?

In any case, it seems like font-variant-position is intended to handle my specific issue, though it doesn't seem to work in practice (yet).

[tabatkins]

Why should one have to write JS for these things?

Because there's no reasonable way to talk about a single individual font file in CSS, but there is in JS. CSS just has a concept of a font stack, composed of family names, each of which is composed of 1 or more composite font faces, each of which is composed of one or more individual font faces/files (you can combine multiple faces into one composite face via unicode-range). It's the individual faces that you need to know about to tell if a variation axis exists.

And why should one have to use the font loading API if they aren't even loading any fonts, but instead using only the browsers preloaded fonts?

I didn't say you'd use the font loading API. I said you'd use the FontFace API, which happens to be defined in the spec called Font Loading. Nothing needs to be "loaded" to use this. It's just the right API location for this sort of ability to live.