W3C home > Mailing lists > Public > www-style@w3.org > March 2012

Re: [css3-font] unquoted font family names with whitespace

From: Simon Pieters <simonp@opera.com>
Date: Mon, 19 Mar 2012 06:32:50 +0100
To: "John Daggett" <jdaggett@mozilla.com>
Cc: www-style@w3.org
Message-ID: <op.wbekc0vtidj3kv@simons-macbook-pro.local>
On Mon, 19 Mar 2012 01:01:09 +0100, John Daggett <jdaggett@mozilla.com>  
wrote:

>
> Simon Pieters wrote:
>
>> > Unquoted family names must be sequences of CSS identifiers, in both
>> > CSS 2.1 and CSS3 Fonts.  So you're right, family names don't need to
>> > be quoted but I still think recommending quotes is a good rule of
>> > thumb, it avoids authors needing to understand precisely what is and
>> > isn't a "sequence of CSS identifiers" (the spec does show several
>> > examples of invalid names).
>>
>> In that case the spec should recommend to always use quotes for font
>> family names. I'm fine with that outcome, but I'm not so happy with
>> the current text.
>
> No, I'm not suggesting (nor does the spec suggest) that family names
> *always* be quoted, either as a requirement or as a rule of thumb.
> Authors have quoted names in the past because browsers didn't always
> support names with spaces.  With user agents that follow the CSS 2.1
> rules, names only need to be quoted when they aren't a sequence of CSS
> identifiers.  But since authors are human and don't keep parsing rules
> at their fingertips, I think it's fine to suggest a rule of thumb.
> Maybe it's not some shining ideal but it works in practice.

Removing the mention of whitespace would make the rule of thumb simpler.

>> > In real world use, this is rarely a problem.  Font family names may
>> > have spaces but typically don't start with numbers or use punctuation
>> > characters.  Yes, I'm sure there are exceptions out there but they
>> > generally aren't used on the web or in interchange situations (e.g.
>> > email).
>>
>> Still, many authors quote their font family names if they have spaces  
>> (and
>> omit the quotes if they don't), because that's what they have been told  
>> to
>> do.
>
> That's because of spotty implementation support in the past.

Ah. Well then, surely it's safe to change the recommendation now to be  
more accurate and not mention whitespace.

> As more
> and more authors understand that this is a rule of the past, we'll move
> beyond it.  Font family names which can't be left unquoted (e.g. Courier  
> 10)
> are relatively rare in practice.
>
> We've come up with a reasonable syntax rule (i.e. family names that
> aren't sequences of CSS identifiers must be quoted) but if authors want
> to quote all family names, that works too.  The specs define the exact
> rules but list a rule of thumb useful for those who don't want to delve
> into whether a given font family name matches the syntax rule or not.
>
>> > What *is* still a problem is the way in which browsers recognize as
>> > family names a variety of other font names.  For example, "Arial" is
>> > the name of a font family, names given to individual faces within that
>> > family are *not*.  Incorrect name matching happens with many GDI-based
>> > browsers (Chrome/IE7+8/Opera) which recognize full names (e.g. "Arial
>> > Bold").  It occurs with Webkit browsers on OSX/iOS which recognize
>> > Postscript names (e.g. "Arial-BoldMT").  These browsers will all fail
>> > the CSS 2.1 test suite tests that check for this.  This is a real
>> > problem because authors will use "Arial Bold", see that it works in
>> > their given browser/environment and assume that it will work across
>> > platforms/browsers.
>>
>> That's a separate issue.
>
> Sure, my point is simply that family names that require quotes aren't a
> problem in general but other issues, such as the way user agents match
> different additional naming schemes or handle localized family
> names *are* problems!
>
> Cheers,
>
> John Daggett

cheers
-- 
Simon Pieters
Opera Software
Received on Monday, 19 March 2012 05:33:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 May 2012 03:48:52 GMT