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

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

From: John Daggett <jdaggett@mozilla.com>
Date: Sun, 27 Jan 2013 16:41:54 -0800 (PST)
To: www-style list <www-style@w3.org>
Message-ID: <39151885.1056880.1359333714479.JavaMail.root@mozilla.com>
Simon Sapin wrote:

> >> In §5.1 Matching font styles:
> >>
> >>> 2. If the family name is unquoted and is a generic family name,[…]
> >>
> >> <generic-family> values are CSS-defined keywords, which §3.1 of
> >> css3-values clearly defines as ASCII case-insensitive.
> >
> > Probably not appropriate to bring this up as an error quite yet,
> > given that we're still discussing the issue of whether they're CI
> > or not.
> Sorry I wasn’t clear. I certainly did not mean to say this is an
> error. On the contrary, this is the part (for comparison) that is
> well-defined. We may or may not change that definition later; that’s
> another story. (And since all CSS-defined keywords are ASCII it
> doesn’t change much.)
> 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.

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.


John Daggett
Received on Monday, 28 January 2013 00:42:21 UTC

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