Re: [css3-fonts] Case insensitivity of <family-name>

Le 28/01/2013 01:41, John Daggett a écrit :
>> The point of my email was that <family-name> (that is, a non-generic
>> name) is not as well defined as <generic-family>. It’s said to be
>> case-insensitive, but not what kind. The part of css3-values about
>> pre-defined keywords applies to <generic-family> but not
>> <family-name>.
> Thanks for bringing this up Simon, I think it's an important case to
> consider. As Tab says, I think we should consider it after making a
> clear decision on how user-defined identifiers are handled.  But I
> think the answer is somewhat subtle, which is the point I'm guessing
> you were wondering about.
>
> The value of the 'font-family' property can contain (1) a font family
> name intended to match a platform font family or (2) an author-defined
> font family name used in @font-face rules or (3) a generic family.
> This makes it somewhat like the predefined vs. user-defined counter
> name case but with one important distinction - font family names can
> be matched using a localized name (e.g. "ヒラギノ角ゴ ProN"), something
> that is not user-defined.

(3) is covered by §3.1. "Pre-defined Keywords" of css3-values. (The 
current draft says ASCII CI.)

(2) is matching font-family properties with font-family descriptors of 
@font-face rules. Both are under the UA’s control, so it makes sense to 
use the same rules as other user-defined identifiers. (Whatever these 
rules end up being.)

(1) is, as you say, more subtle. I don’t know much about font 
subsystems. Are UAs expected to get a list of all fonts available on the 
system, all variants of their family names, and do the matching themselves?


> In this case I think Unicode caseless matching *is* appropriate (i.e.
> C+F rules, no normalization or locale-dependent matching rules) and,
> as such, needs to be defined somewhere explicitly so other specs can
> reference it.  As with all CSS keywords, generic keywords should
> however be matched using ASCII case insensitive matching (i.e. silly
> things like a name containing a long-S in 'sans-serif' shouldn't
> match).  Some will groan that this is terribly inconsistent but for
> authors I doubt this matters - generic keywords will match as they
> always have and localized family names (which many browsers don't
> support properly today) will be handled consistently.


-- 
Simon Sapin

Received on Monday, 28 January 2013 11:11:18 UTC