[csswg-drafts] [css-fonts] Don't require browsers to always match every generic font family to a concrete font family (#4442)

litherum has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-fonts] Don't require browsers to always match every generic font family to a concrete font family ==
CSS Fonts currently [says](https://drafts.csswg.org/css-fonts-4/#generic-font-families):

> Each generic font family must always map to at least one matched font face.

I'd like to propose deleting this sentence because it does not accomplish its goal, nor could it ever accomplish its goal. This is because browsers are free to map the generic font families to any concrete font or font stack, regardless of that font's Unicode coverage. There's no guarantee that, when an author specifies a generic font family, that the concrete font can actually be used for any of the content on the page. Indeed, the mapped font could be a font which supports 0 characters.

I'd also like to add a sentence encouraging authors to use generic font families in their `font-family` lists. This provides a signal for what kind of font the author desires, regardless of whether or not it actually ends up being used. WebKit (and other browsers too?) will consider this kind of signal when we "fall off the end" of the `font-family` list and have to pick a font for the content but can't use any of the fonts in the specified list.

I'm not actually proposing any behavior change in browsers. The difference between `fantasy` mapping to a font that supports 0 characters, and `fantasy` not mapping to any font, is untestable. Untestable things shouldn't be normative in specs.

This has implications for the new `ui-serif`, `ui-monospaced`, and `ui-rounded` [font families](https://github.com/w3c/csswg-drafts/issues/4107). We [resolved](https://github.com/w3c/csswg-drafts/issues/4107#issuecomment-532111422) that these shouldn't map to any concrete fonts on platforms that don't have an appropriate UI font for them. Therefore, under the current text, they can't be generic font families, and should instead be a new class of fonts. I don't think it's valuable to have two distinct classes of fonts in the spec when their difference is meaningless and untestable.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4442 using your GitHub account

Received on Tuesday, 22 October 2019 22:56:20 UTC