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

On Sat, 17 Mar 2012 04:09:55 +0100, John Daggett <jdaggett@mozilla.com>  
wrote:

> Simon Pieters wrote:
>
>> "To avoid mistakes in escaping, it is recommended to quote font
>> family names that contain white space, digits, or punctuation
>> characters other than hyphens:"
>>
>> http://dev.w3.org/csswg/css3-fonts/#propdef-font-family
>> http://www.w3.org/TR/CSS21/fonts.html#font-family-prop
>>
>> What mistake in escaping can one do when a font family name contains
>> whitespace? Whitespace doesn't need escaping (unless a font has
>> something funny like a tab character or two subsequent spaces, but
>> such fonts don't exist). Unquoted font family names with spaces work
>> fine. Don't recommend quoting them.
>>
>> Unescaped unquoted font family names that start with a digit or
>> contain punctuation characters other than hyphen will break *even if
>> there is no whitespace*.
>
> 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.

> The email interchange problem with
> Outlook 2007 is unfortunate but I don't see a reason to update the
> wording because of bugs in legacy versions of software.

I agree.

> 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.

> 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.

> 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) which recognize full names (e.g. "Arial
> Bold").  It occurs with Webkit browsers on OSX/iOS which recognize
> Postscript names (e.g. "Arial-BoldMT").  The current shipping versions
> of Chrome/Safari 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.
>
> Regards,
>
> John Daggett
>
> Arial variations illustrating what is and isn't matched:
> http://people.mozilla.org/~jdaggett/tests/arialvariations.html
>
> Full name matching:
> http://test.csswg.org/suites/css2.1/20110323/html4/font-family-name-013.htm
>
> Postscript name matching:
> http://test.csswg.org/suites/css2.1/20110323/html4/font-family-name-014.htm


-- 
Simon Pieters
Opera Software

Received on Saturday, 17 March 2012 10:24:09 UTC