@font-face, Font Families and Computed Values ?

Hi,

I have a question about Font Family and the Computed Value. The spec  
[1] says that the Computed Value should be "As specified" but there is  
some ambiguity there:


# 1. Should the Computed Value be returned with or without quotes?

Examples:
- font-family: "Times New Roman", serif;
- font-family: Times New Roman, serif;

The Spec claims that font family names containing white space should  
be quoted, but in the CSS3 Fonts spec first example[2] it only does so  
for one of the two fonts with whitespace in the name ("Heisi Mincho  
W3" and Arial Unicode MS). This discrepancy only amplifies the lack of  
clarity on what a UA should do with quotes. Some UAs actually add  
quotes in the computed value even when they're not specified.


# 2. What should the UA do for internal defaults?

The following three examples produce very differing results:
- font-family: serif;
- font-family: inherit; (on the highest specified level, i.e. it  
inherits from the browser itself)
- (nothing at all)

Some UAs allow the user to specify a font of choice for serif, sans- 
serif and monospace, others just for default & monospace. Typically,  
"default" is set to a serif font by default but a user can set it to a  
sans-serif font of course. The Computed Value seems to be somewhat  
arbitrarily chosen by existing UAs, perhaps due to lack of direction  
here. In particular, "serif" is a browser internal that technically  
maps to some font but it appears unclear whether the Computed Value  
returned should be "serif" or the font name. In Webkit's case, even  
"serif" itself wouldn't return as specified as it maps to the internal  
"-webkit-serif" — but that could be a bug that needs to be filed.


# 3. What about :first-letter and :first-line pseudo elements that  
change possibly *all* of the element's rendering?

Example:

<p>w</p>

p { font-family: Times, serif; }
p:first-line { font-family: Helvetica, sans-serif; }
p:first-letter { font-family: Courier, monospace; }

I reckon this should have NO impact on the Computed Value since the  
pseudo elements would effectively constitute a new element inside the  
p element, but confirmation of that would still be nice.


# 4. And lastly, what about @font-face fonts?

What should a UA do with fonts listed that are @font-face embedded when:

- the UA does not (yet) support @font-face?*
- the embedded @font-face font file is Not Found?

Should a UA stick to the "As specified" Computed Value even for fonts  
it doesn't actually include and thus wouldn't render? This already  
applies for lists of fonts without any use of @font-face, but the new  
embedding of fonts makes this issue more pertinent.

I guess at the heart of all these questions lies the bigger issue: is  
it right for Computed Value to be returned "as specified" when the  
specified value has a nearly-100% guarantee of NOT representing what  
is actually the computed value as rendered by the UA?

The only message I could find (in an admittedly rudimentary search  
through the archives) about all this is Hixie explaining in 2006 that  
the Computed Value should simply be as specified and ignoring presence  
of fonts, but even that felt inconclusive for issues #1 and #2 in  
particular.


Cheers,
Faruk


* this may be an irrelevant issue as all next major UA releases will  
support @font-face if they don't already

[1] http://www.w3.org/TR/CSS21/fonts.html#font-family-prop
[2] http://www.w3.org/TR/css3-fonts/#font-family-prop

Received on Tuesday, 24 March 2009 03:07:40 UTC