Bug 18002 – @font-face { src: local("font"); } matches font family, not full face name

• Status: RESOLVED
• Resolution: INVALID
• Component: CSS

[Chris Lawrence]

Section 2.5 of the CSS3 Web Fonts specification (http://www.w3.org/TR/css3-webfonts/#referencing) says, in part:

"The locally-installed <font-face-name> is the full font name of a locally installed font. The full font name is the name of the font as reported by the operating system and is the name most likely to be used in reader style sheets, browser default style sheets or possibly author style sheets on an intranet. Adornments such as bold, italic, and underline are often used to differentiate faces within a font family. For more information about full font names please consult the notes below."

and one example is:

"src: local("BT Century 751 No. 2 Semi Bold Italic")
    references a particular face of a locally installed font"

However, a stylesheet (such as the one referenced by the page above, found at http://blog.lordsutch.com/fonts/faces.css) that specifies the full face--e.g. "DejaVu Sans Bold Oblique"--using the local("") syntax does not match a font and downloads the font at the lower priority URI.  Safari 3.1 and the nightly (at least on OS X 10.5.2) only recognizes as locally-installed fonts specified by their family name, which seems incorrect and likely to lead to interoperability problems, as the family name alone might be matched by other browsers to the normal-weight, normal-slant variant of the typeface.

(The current stylesheet contains both the correct specification and that recognized by Safari/Webkit, as I'd rather every Safari user not download 2 MB of fonts when visiting my site for the first time even if they are already locally-installed.)

[Dave Hyatt]

"and is the name most likely to be used in reader style sheets" makes me think WebKit's current behavior is correct...

[Chris Lawrence]

On the other hand, section 3.2 (http://www.w3.org/TR/css3-webfonts/#aname) says:

"3.2. Full font name

This is the full name of a particular face of a font family. It typically includes a variety of non-standardized textual qualifiers or adornments appended to the font family name. It may also include a foundry name or abbreviation, often prepended to the font family name. It is only used to refer to locally installed fonts, because the format of the adorned name can vary from platform to platform. It must be quoted."

The "full name of a particular face" part, along with the discussion of "adornments appended to the font family name," suggests to me that it should be the "full name" of the font face, not just the family name.

Also, in section 2.5 it refers only to "reader style sheets,
browser default style sheets or possibly author style sheets on an intranet" - not to *author* style sheets.

Further I think that S. 2.5 is trying to say something like "@font-face rules in reader style sheets, browser default style sheets, or possibly author style sheets on an intranet will typically use local()" (since you wouldn't really want to download your default fonts from a remote URI every time you launch the browser or hardcode local font paths, e.g. url("file:///Library/Fonts/GillSans.dfont"), in a stylesheet), rather than saying anything about font-family properties outside of @font-face rules.

[Dave Hyatt]

You need to be able to target specific variants via local() in order to be able to test for missing variants of a specific font family.  The question is whether or not using the parameters in the @font-face declaration are good enough for this purpose.

[Nicholas Shanks]

I think the specification is in error, and the font name in @font-face rules should be the family name as currently implemented in WebKit. The other declarations in the @font-face block determine what face is represented within that family.

[John Daggett]

The local() syntax specifies a face, not a family.  And Safari does support the syntax but only via Postscript names on Mac OS X, not full font names:

@font-face {
  font-family: Ornaments;
  src: local(HoeflerText-Ornaments);
}

This is more an artifact of Mac font API's.

[Nicholas Shanks]

Ah yes, sorry. I was confusing myself while reading this bug and getting the src and font‐family properties muddled.

[Tab Atkins]

It looks like this in INVALID, then, since the behavior difference is due to different font APIs on Mac, not a misimplemented feature.  You can indeed select a particular face with local(), you just have to use a different name on Safari/Mac than on other platforms.

(It makes me sad that face names are so hard to select properly, but there's not a lot we can do now, since we're dependent on the platform APIs.)