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.