Closed Bug 499421 Opened 11 years ago Closed 8 years ago

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

Categories

(Core :: Graphics, defect)

defect
Not set

Tracking

()

RESOLVED INVALID

People

(Reporter: tom, Unassigned)

References

()

Details

(Whiteboard: INVALID?)

Attachments

(2 files)

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
OS: Linux → All
Version: unspecified → Trunk
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.
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?
The spec is quite clear here; it doesn't require interpretation.
It seems odd to me then, that Opera, Safari and IE8 all have it the other way.
This is how W3's test browser/editor 'Amaya' displays the test case shown above.
Component: General → Graphics
Product: Firefox → Core
QA Contact: general → thebes
Hardware: x86 → All
Summary: W3 CSS 2.1 font-family algorithm not followed correctly → 'font-family' should fall back to fonts on ancestors before falling back to defaults
Whiteboard: INVALID?
Invalid based on on David and John's analysis.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.