499421 - 'font-family' should fall back to fonts on ancestors before falling back to defaults

Status: RESOLVED INVALID

(Core :: Graphics, defect)

Description

[Thomas Moitie]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090619 Minefield/3.6a1pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090619 Minefield/3.6a1pre

Say in a CSS page you have the following: 
body{ font-family:Arial, serif; }
p{ font-family: not-a-real-font-name; }

In Firefox's default procedure, it would override the font-family in body and ignore its contents for the p tags. 

According to the CSS2.1 standards, 15.2 "Font matching algorithm": "If there is no matching font face within the 'font-family' being processed by step 2, and if there is a next alternative 'font-family' in the font set, then repeat step 2 with the next alternative 'font-family'."

This leads me to believe that instead of ignoring the body font-family, Firefox should be using them as a fall back. 

Reproducible: Always

Steps to Reproduce:
1. Go to http://developer.yahoo.com/yui/examples/fonts/fonts-family_source.html
2. See test 6 in the source code
Actual Results:  
test6 shows as serif, the default font for my Firefox.

Expected Results:  
test6 should have shown as "arial,helvetica,clean,sans-serif;", as set in fonts.css

Comment 1

[John Daggett (:jtd)]

The analysis here is not quite right.  The CSS 2.1 font matching algorithm describes a set of steps for matching a given set of font family names but it doesn't define fallback behavior as you describe.

http://www.w3.org/TR/CSS21/fonts.html#algorithm

Example: body { font-family: Arial, Helvetica, SillyFont; }

Step 2 describes how to find a face for a single family name in this list.  Step 3 just says to iterate to the next family name in the list if a match was not found.  Step 5 describes what to do if none of these font families are found, "if there is no font within the family selected in 2, then use a UA-dependent default 'font-family' and repeat step 2".

Example: p { font-family: sillybunt; }

In this case, Firefox use pref fonts, then system-wide font fallback but Opera/IE appear to iterate over the font-family list of the containing element.  Webkit also seems to be using a default font.

Comment 2

[Thomas Moitie]

It seems that this is an area of the specification that requires interpretation. The Yahoo developers, Opera, Safari and IE take the side of over-riding font as seen in test 6 of that YUI font example - from what I have seen only Gecko does not. Could we seek clarification on the W3 mailing lists as to the interpretation?

Comment 3

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

The spec is quite clear here; it doesn't require interpretation.

Comment 4

[Thomas Moitie]

It seems odd to me then, that Opera, Safari and IE8 all have it the other way.

Comment 5

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: clearer testcase

Comment 6

[Thomas Moitie]

Attachment: Image of Amaya displaying testcase

This is how W3's test browser/editor 'Amaya' displays the test case shown above.

Comment 7

[Joe Drew (not getting mail)]

Invalid based on on David and John's analysis.