[css-fonts] Is "default caseless" matching really required for font names?

[tabatkins]

Per https://drafts.csswg.org/css-fonts-4/#localized-name-matching, font-family names are matched against names in font files using the "default caseless" matching algorithm defined by Unicode.

While the rest of CSS is either only ASCII case-insensitive (matching a-z to A-Z; otherwise case-sensitive) or fully case-sensitive (exact codepoint equality), this algorithm sits in a middle ground, allowing strings like "ſilver" to match "silver".

I expect that this algorithm is required due to legacy constraints with how font names work across platforms, but I'm filing this issue to ensure that's actually the case, and it's not just something somebody thought was reasonable at some point in the past, but could now be swapped out for the simpler ASCII case-insensitive matching.

[svgeesus]

That text was added 2 years ago by @litherum but directly comes from Fonts 3 and was I believe added by @nattokirai

I don't see any WPT tests for that section.

I, too, think this is for legacy constraints on font name matching. I can try to find out more.

[aphillips]

The specific algorithm in Font3 is slightly different from I18N's recommendations in String Matching, since it adopts Default Caseless Matching and we recommend a form of Default Canonical Caseless Matching.

From a practical point of view, I don't think that normalization (or lack thereof) in font names is a common problem. However, caseless matching (and the casefold underlying it) has normalization considerations of its own, hence, we suggest following D145 in Unicode vs. the specified D144.

I would suggest that in addition to referencing the section (3.13) in The Unicode Standard, that the specific rule be cited (or cite [CHARMOD-NORM] instead).

Finally, there is the design question @tabatkins raises. The problem here is that style sheet authors need to match the font name without having strict access to the font itself. The font name can be localized (including using a non-Latin script), and both the localized and (where another script applies) romanized name are not limited to ASCII. Caseless matching presents several problems here (which our String Matching docs spells out a lot, so I shan't repeat them). A key one for users is how to get a reliable match. The difficult part is that we can't really make font names locale-sensitive when matching and this creates problems for languages (such as Turkish) with special case mappings.

But ASCII case-insensitivity is not the solution. I18N supports ASCII case-insensitivity for features whose grammar is limited to ASCII. CSS is mostly this, except for user-defined IDs. We've spilled a lot of virtual ink over the perversity of the results (grün != GRÜN but == GRüN for example).

I think what we have now is a compromise and is reasonable in that, unlike the case where the stylesheet and page authors have at least some opportunity to agree, the style sheet author hasn't much control over the font vendor (or which font vendor served up a given face). This is the same reason that this is trying to be case insensitive in the first place, I'm guessing.

To sum up, I'd probably not mess with the requirement, except perhaps to clean up some editorial stuff--and maybe consider the normalization bits.

[svgeesus]

I feel that the next step is to get expert opinion on the extent to which case folding in font name matching is depended upon in the wild. There are several sources of such data, but one obvious one is the SC29/WG11 (the ISO "OpenType") ad-hoc group, which is an open public list.