W3C home > Mailing lists > Public > www-style@w3.org > February 2013

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

From: Jonathan Kew <jfkthame@googlemail.com>
Date: Sat, 16 Feb 2013 19:46:40 +0000
Message-ID: <511FE220.2070606@gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: www-style list <www-style@w3.org>
On 16/2/13 19:07, Tab Atkins Jr. wrote:
> 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.

I don't think that's right. The important point is that with C+S, every 
mapping is 1:1, so the required table can be very simple in structure, 
and it is guaranteed that the folded string will be exactly the same 
length (if counted in Unicode characters, or in UTF16 code units).

With C+F, there are single characters that will be expanded to two or 
three characters by the mapping. This requires a more complex table to 
provide the mapping data, as well as additional code to handle the 
potential expansion of the font-family name string during case folding.

It's not a huge burden to implement - we can certainly do so if 
necessary - but IMO the cost is clearly non-zero, while the benefit is 

Given the resistance there seems to be to implementing a -full- solution 
to string-equivalence issues, I don't see why we'd require people to 
implement anything more complex/expensive than a purely 1:1 mapping in 
this particular case.

Received on Saturday, 16 February 2013 19:47:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:26 UTC