W3C home > Mailing lists > Public > www-style@w3.org > November 2008

Re: [css3-fonts] duplication and @font-face rules

From: John Daggett <jdaggett@mozilla.com>
Date: Tue, 11 Nov 2008 04:55:47 -0800 (PST)
To: "L. David Baron" <dbaron@dbaron.org>
Cc: www-style@w3.org
Message-ID: <17404114.52781226408147737.JavaMail.root@cm-mail01.mozilla.org>

> 1. Duplicated descriptors in an @font-face rule
> ===============================================
> I'll start with the easiest of the three issues:  when the same
> descriptor appears twice in an @font-face rule, which one or ones
> matter?  
> CSS 2.0 is clear on this:
>   # If a font descriptor is duplicated, the last occurring
>   # descriptor wins and the rest must be ignored.

This makes the most sense to me.

> 2. Handling of lists of values of the 'src' descriptor
> ======================================================
> The second issue is that the spec doesn't describe how a user agent
> should process multiple values of the 'src' descriptor.  In
> particular, when the 'src' descriptor is a list of values, there
> seem to be two reasonable possibilities:
>   (A) The user agent uses the first of those values for which it has
>   a usable font (e.g., a local() font that is present or a url()
>   that is in a format it supports) and ignores the rest.
>   (B) The user agent uses all of the values for which it has a
>   usable font, picking each glyph from the earliest in the list that
>   has a glyph for the character.
> (B) seems like it has some advantages, particularly when local() and
> src() are combined, and the font available locally may have more or
> fewer glyphs in it depending on what the user has chosen to install.
> It also feels more CSS-like to me (which could mean it fits author
> expectations better, although maybe not).
> (A) seems like it may have some advantages in terms of speed or
> bandwidth usage.
> However, current implementations in WebKit nightlies and in Gecko
> nightlies seem to do (A).

I actually think it's important to separate font loading behavior from
font fallback, so that web authors have more control over when fonts are
downloaded and used.  Method (B) may seem more like normal CSS fallback
but it gives authors less control.

Example: use an SVG font as a substitute for when Futura not available

  @font-face {
    font-family: MyFutura;
    src: local(Futura-Medium), url(fonts/MyGeometricModern.svg) format("svg");

  body { font-family: MyFutura, sans-serif; }

With method (B), user agents supporting SVG fonts would *always*
download the SVG font in fallback situations, even if the web author
already knew that both fonts supported the same set of characters.

Example: set up a font for use with Arabic text that works across
different platforms

  @font-face {
    font-family: Lateef;
    src: url(../fonts/LateefRegAAT.ttf) format("truetype-aat"), 
         url(../fonts/LateefRegOT.ttf) format("opentype");

  body { Lateef, sans-serif; }
In this case, user agents under Mac OS X would use the AAT font while
user agents on other platforms would skip the AAT font and use the
OpenType font.  In the case of fallback for non-Arabic text, method (B)
would require both fonts to be downloaded under Mac OS X.

Example: set up an alias for Japanese fonts on different platforms

  @font-face {
    font-family: Japanese;
    src: local(Meiryo), local(HiraKakuPro-W3), local(IPAPGothic);

  body { Helvetica, Japanese, Arabic, sans-serif; }
Method (A) allows a simple way to just lookup a character in one font
per possible script.  Method (B) requires a lot of extra lookups.

Method (B) mimics normal font fallback, so it's possible to get the same
results with a normal font-family list using fonts defined by simple
@font-face rules.  Method (A) can't be simulated in a user agent that
uses method (B).

> 3. Handling multiple @font-face rules defining the same fonts
> =============================================================
> The third issue is somewhat similar to the second, except it
> involves some additional forward-compatibility issues:
> Given two @font-face rules that describe the same font but have
> different 'src' descriptors, which fonts are used?  For example:
> @font-face {
>   font-family: "Foo";
>   src: url(a.ttf);
> }
> @font-face {
>   font-family: "Foo";
>   src: url(b.ttf);
> }
> body { font-family: "Foo", Arial, sans-serif; }
> In this case, does the search for glyphs look in:
>  (1) a.ttf, then b.ttf, then Arial, then other sans-serif fonts
>  (2) b.ttf, then a.ttf, then Arial, then other sans-serif fonts
>  (3) a.ttf, then Arial, then other sans-serif fonts
>  (4) b.ttf, then Arial, then other sans-serif fonts
> ?
> Right now WebKit nightlies appear to do (2) and Gecko nightlies
> appear to do (4).
> I think I prefer (4) because:
> (a) @font-face rules that are identical might actually differ in
> descriptors that the user-agent doesn't understand or can't parse.
> If these descriptors are like 'font-weight', then in doesn't matter
> what the behavior is, and authors can work around the lack of
> support for those descriptors by choosing one of the fonts over the
> other by putting the @font-face rules in a particular order
> (whichever way they want), no matter which solution is chosen (as
> long as the solution is consistent across browsers).  However, if
> the unknown descriptor (or descriptor with an unknown value) is one
> like 'unicode-range', the user-agent is clearly better using both of
> the sources provided.
> (b) It has more similarity to the way descriptors like
> 'unicode-range' are handled.
> (c) Again, it seems somewhat more CSS-like to me.

I agree, for two @font-face rules that specify the same set of font
descriptor values with different src values, the first rule should
effectively be ignored.  I'm surprised that WebKit uses (2) that doesn't
make a lot of sense.
Received on Tuesday, 11 November 2008 12:56:29 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:41 UTC