Re: [csswg-drafts] [css-fonts] Is "default caseless" matching really required for font names? (#4652)

The specific algorithm in Font3 is slightly different from I18N's recommendations in [String Matching](https://www.w3.org/TR/charmod-norm), 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.

-- 
GitHub Notification of comment by aphillips
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4652#issuecomment-618637634 using your GitHub account

Received on Thursday, 23 April 2020 20:08:50 UTC