- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Sat, 16 Feb 2013 11:07:45 -0800
- To: Jonathan Kew <jfkthame@googlemail.com>
- Cc: www-style list <www-style@w3.org>
On Sat, Feb 16, 2013 at 8:29 AM, Jonathan Kew <jfkthame@googlemail.com> wrote: > On 15/2/13 22:07, fantasai wrote: >> >> CSS3 Fonts > > >> jdaggett: First topic is case-sensitivity of font family names >> jdaggett: Talked about this yesterday >> jdaggett: I put last night wording into spec to define the exact >> algorithm >> to be used >> <jdaggett> http://dev.w3.org/csswg/css3-fonts/#font-family-casing >> jdaggett: Would like to take a second to resolve on this >> jdaggett: Points at default caseless matching algorithm in Unicode spec >> jdaggett: You case-fold each string >> jdaggett: Use case mappings defined by C/F statuses in CaseFolding.txt > > > Given that the Unicode-caseless-matching issue here is being addressed for > such a narrow problem space, I'm a bit surprised at the choice of "full" > (C+F) Unicode case folding, rather than the equally well-defined but > significantly simpler (and cheaper to implement) "simple" (C+S) folding. > > As neither version can be completely "correct" in the sense of matching a > native-speaker understanding of equivalence in all situations (impossible to > achieve without addressing the issues of normalization and of > locale-dependent mappings, at least), I would have thought that the marginal > benefits of the "full" folding would be insufficient to justify the added > complexity. (Do we really expect to see fully-accented Greek used in > font-family names?) That's what the i18n WG recommended, so shrug. I don't think it's any cheaper to implement, and least not in any significant sense. C+F can be done with a simple substitution table. Maybe C+S can be done with a smaller table, but aside from a tiny bit of binary size, the two would be identical in complexity. ~TJ
Received on Saturday, 16 February 2013 19:08:32 UTC