- From: John Daggett <jdaggett@mozilla.com>
- Date: Sun, 27 Jan 2013 16:41:54 -0800 (PST)
- To: www-style list <www-style@w3.org>
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. Regards, John Daggett
Received on Monday, 28 January 2013 00:42:21 UTC