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

There are a few sources of duplicate information relating to
@font-face rules that css3-fonts (and, in most cases, CSS 2.0)
aren't particularly clear about, at least based on what I've found
in the specs so far.

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.
http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#font-descriptions

although it could have been clearer that this was referring to the
case of two occurrences of the same descriptor within a single
@font-face rule.  css3-fonts should say something about this case
(hopefully the same thing).

To clarify what I'm talking about with an example, all I'm saying
is:

@font-face {
  font-family: "Arial";     /* this gets ignored */
  font-family: "Helvetica"; /* this one wins */
  src: local(Arial), local(Helvetica);
}

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

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 think css3-fonts should provide clear answers to all three of
these questions so that implementations converge on a single
behavior here.  (CSS 2.0 had a clear answer only to the first, as
far as I can tell.)

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

Received on Thursday, 6 November 2008 18:43:31 UTC