Hello again, I've noticed a bug today in the cascading of font-family names. It's not related to yesterday's @font-face patch - it's in existing code.
CSS that causes the problems to exhibit is like this:
p.name {
font-family: "Minion Pro";
}
Note that there's no fallback system font specified as would be usual.
The client-visible symptom is that, with CSS like this, the list of font names
returned by css_computed_font_family is always empty rather than containing the
specified font name.
The cause is that, in css__compose_font_family, the child's font-family list
contains the correctly parsed font names, but the type, because no system font
was specified, is still CSS_FONT_FAMILY_INHERIT. This causes the font list to
be overwritten with the parent's list.
The spec (CSS 2 and 3) doesn't seem to say specifically what should happen if
there's no system font specified. Existing browsers seem to fall back on the
browser default font as a last resort (so not the parent's font, which might
also make sense).
I've fixed the problem by following their lead; in css__cascade_font_family, if
there are specific fonts used, I call ua_default_for_property and use the
system font it returns as the system font value instead of leaving
CSS_FONT_FAMILY_INHERIT.
I also took the opportunity to clean up css__compose_font_family a bit - the
local variable naming in it referred to URLs when it's really using font family
name strings, not URLs.
Patch attached.
Jamie.
font-family.diff
Description: Binary data
