Csswg-drafts: [css-fonts] Allow UA to not download font hints if it would have ignored them

[davelab6]

@zachleat proposed a uses-hints media query in order to have different @font-face rules (URLs really) to fonts with and without hinting data - which can be up to 50% of the file size, but is ignored on most systems (iOS, Android, Chrome)

https://twitter.com/zachleat/status/1127548970128019456?s=19

[litherum]

Why media query? Why not modify @font-face instead? It would be simpler and wouldn't require nested at-rules. I believe we already have the infrastructure to do this; we could add a production to the font-technology term in https://drafts.csswg.org/css-fonts-4/#src-desc

[moyogo]

As far as I know, Android and Chrome use hinting if it is there. I assume iOS uses it some way or another as well, if it does anything like macOS.

This should could be requires-hints instead.

[litherum]

My biggest concern is I’m not sure how many existing fonts out there already have versions with hints and without hints. If this keyword can’t be used on 99% of existing fonts, I’m not sure it’s worth it.

[litherum]

Also, just saying “hinting” may be insufficient, as there are different possible ways to represent hints inside a font file (e.g. TrueType instructions, and the vstem family of commands)

[AmeliaBR]

This seems to me like a logical extension of the format(<format> supports <technology>) specifier. As currently defined, the supports specifier allows authors to limit font downloads to user agents that support opentype features, color fonts, or variable fonts (see #633 and #2540).

We could define a hints font technology keyword, probably with parameter format for different types of hinting. Then, you could have one source file restricted to browsers that support the relevant type of hinting, and the simplified font file for other user agents:

@font-face {
  font-family: MyWebFont;
  src: url("font-full.otf") format(opentype supports hints(truetype)),
     url("font-no-hints.otf") format(opentype);
}