[css-fonts-4] [varfont] local() and variation fonts

[litherum]

Migrated on behalf of @kuettel:

https://github.com/w3c/csswg-drafts/blob/master/css-fonts-4/Overview.bs#L342

While format() is being refined to support variation fonts, e.g. format ("woff-variations") or via an additional parameter (see: #513), similar consideration should be given to local().

Specifically, one should be able to use locally available variation fonts but fallback to downloading the font when the locally available font does not support variations. Perhaps via an additional parameter as well? e.g. local("full name", "variation"), which then would only use "full name" if it was variation ready.

[litherum]

Migrated on behalf of @jfkthame:

This is just a special case of a more general problem with src:local() ... there's no way to know whether the locally-installed font with a given name is actually the font that was intended. In the worst case, there might be a completely unrelated font that happens to have the same name; more commonly, there may be many versions of a given font in existence, sharing the same name but with different character repertoires and other capabilities (OpenType features, for example). The author has no way of specifying what version or capabilities are required for the local font to be suitable.

[litherum]

The concept of variation discovery is explicitly not covered in this spec. Currently, there is no way of web content knowing which axes a font supports. This might come later, but for now, it is out of scope.

A UA which is concerned with fingerprinting may wish to ignore user-installed fonts for the purposes of font selection. Such a UA would not have the problem of "the user installed a broken version of font X and now my webpage looks broken."

Either way, solving this problem would best be done in another effort, as it (at its core) isn't directly related to variation fonts.

Relatedly, there is currently no way to do this with OpenType features. If/when support is added in the future, it should be added for both technologies.

[litherum]

I'd like to list a few scenarios:

1. An OS is released which understands variations and expands a preexisting font to support variations. Web authors start specifying variation values in their CSS. New systems work correctly with variations. Old systems don't understand variations at all, so there is no font (not even a web font) that can show the desired variation values. In this situation, the web author needs to define fallback for older systems (which is discussed elsewhere).
2. An OS is released which understands variations. Then, in a subsequent OS release, a preexisting variation font is expanded to support more variation axes. In this situation, an identifier of "does this font support variations or not" does not help. Here, you really need to discover which axes a particular font supports, which is discussed in [css-fonts-4] [varfont] Supported variation font axes and font features are not discoverable #520
3. An OS is released which understands variations. Then, in a subsequent OS release, a preexisting non-variation font is expanded to support variations. I'd like to hear from OS vendors to know if this is likely to occur. Any solution to case 2 would also solve this case, so it seems like we should pursue that instead.
4. An OS is released which understands variations. Then, in a subsequent OS release, a new font is included which is a variation font. The regular font-family fallback list handles this case.
5. A user installs an unknown font over top a preinstalled font. There is nothing anyone can do here, because the user-installed font could be anything. The web author has no data upon which to make a decision. (And, as I mentioned before, some UAs may wish to ignore the user-installed font).

[davelab6]

BTW, https://github.com/erinmclaughlin/roboto/tree/everything-in-source-interp has a VF version of Roboto

[litherum]

Perhaps whatever solution we find in #633 should be applicable to local

[litherum]

Duplicate of #633