Re: [CSSWG] Minutes Tucson F2F 2013-02-05 Tue PM I: Fonts

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