[css-fonts-4] [varfont] font format (src descriptor) function should be updated

[litherum]

Migrated on behalf of @kuettel:

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

The format "woff2" should be included as an example, esp. as it is highly relevant in considering how best to support variation fonts.

Currently proposed as "woff-variations" (which then would imply "woff2-variations"), could perhaps better captured as a parameter. e.g. format("woff|woff2|ttf|otf", "variation")

[litherum]

Migrated on behalf of @jfkthame:

The problem with format("woff2", "variation") (etc) is that if I understand correctly, this will not prevent the resource being used by browsers that don't support variation fonts. The current CSS Fonts spec says:

The format hint contains a comma-separated list of format strings that denote well-known font formats. Conformant user agents must skip downloading a font resource if the format hints indicate only unsupported or unknown font formats. If no format hints are supplied, the user agent should download the font resource.

which, at least as implemented in Firefox (I haven't tested this in other browsers) means that if any of the format strings indicates a supported format, the resource will be used.

I think what we want here is the opposite behavior, whereby if any of the format hints indicates an unsupported format or feature, the resource should be skipped. Then an author could say things like

src: url("MyVarFont.woff2") format("woff2", "variation"),
       url("MyFont.woff2") format("woff2");

to provide a variation font to browsers that support it, and a non-variation one to legacy UAs. But that won't work in current Firefox; the first (variation) font will be used even though its "variation" format hint is not supported.

Maybe we can change this in the spec, and expect browsers to adjust as needed? I'm not aware that there has been any real use of multiple format hints at this point; it's not clear to me what current use-case would require them.

[litherum]

The concept of variations are only applicable to certain font formats. Users should not be able to say format("svg", "variations").

Current browsers may interpret a two-argument format() function as a parse error, thereby disregarding the entire src descriptor, which is not what we want. We should do some research to know what happens in this case.

[litherum]

Migrated on behalf of @khaledhosny:

Standard webfont font family with variable fonts, using a new woff2-variations format hint

There was a discussion during web fonts WG F2F meeting on how the format hints are not adequate to cover the granularity of the fonts. For example we have 4 OpenType color glyphs tables, or 3 different sets of layout tables and browsers support different combinations of them and the only way to get some of these features working across browsers and platforms is to ship the font with all of the tables and let the browser select which it supports (and then you can’t do that for some tables that has competing requirements). So I have been thinking may be we need a new capabilities hint that offers more granularity (can be a space or comma separated list) and leave the format hint for the font container as it is now.

[svgeesus]

I like the idea of a capabilities hint, separate from the format hint. This avoids any non-webcompat issues with changing format to use multiple strings, for one thing. I also think the separation is cleaner.

[litherum]

Currently, in Edge and Firefox, extra arguments to format() are not treated as parse errors. This means that, in those browsers, you won't be able to make existing browsers (which don't understand variations) fall back correctly.

There are two possible mechanisms (that I know of) for fallback:

@font-face {
    ...
    src: url("file-novariations.otf") format("opentype");
    src: url("file-variations.otf") format("opentype", "variations");
}

and

@font-face {
    ...
    src: url("file-variations.otf") format("opentype", "variations"), url("file-novariations.otf") format("opentype");
}

In both examples, because these extra arguments are not treated as parse errors in those browsers, current versions of these two browsers will fetch the one marked as needing variations despite the browser not understanding variations. Therefore, neither of these fallback mechanisms will work properly in these two existing browsers.

However, in all browsers today, the following causes existing browsers to correctly ignore the variation font:

@font-face {
    ...
    src: url("file-variations.otf") format("opentype-variations"), url("file-novariations.otf") format("opentype");
}

[litherum]

Given the argument about impossible fallback in existing browsers, I'll close this issue. If you believe this to be an error, please reopen this issue.

[behdad]

Users should not be able to say format("svg", "variations").

Why not? It's not currently implemented in the spec, but it's planned.

[litherum]

SVG 2.0 removed SVG fonts entirely. https://svgwg.org/svg2-draft/

You are probably thinking of the 'SVG ' table inside OpenType fonts. However, format("svg") refers to SVG fonts proper (see the old spec).

[SergeyMalkin]

@litherum

Based on your analysis, this looks like correct statement:

Therefore, neither of these fallback mechanisms will work properly in these two existing browsers.

However, this is not because Edge and Firefox violate the spec as you say:

In both examples, because these extra arguments are not treated as parse errors in those browsers, current versions of these two browsers will erroneously fetch the one marked as needing variations despite the browser not understanding variations.

In fact, per css-fonts-4 spec, these browsers process format hints correctly:

The format hint contains a comma-separated list of format strings that denote well-known font formats. Conformant user agents must skip downloading a font resource if the format hints indicate only unsupported or unknown font formats.

[litherum]

Regardless of who follows the spec and who doesn't, fallback using this mechanism is impossible in those browsers.

I updated the previous post to remove the word "erroneously."

[frivoal]

@litherum fallback using this mechanism is impossible in those browsers, but this appears to be because they follow the spec. So the spec should be changed, and this issue reopened. Or am I missing something?

[litherum]

#633