Created attachment 365531 [details]
If you open http://wiki.developers.facebook.com/index.php/Main_Page with Firefox 3.1 or 3.2 you'll notice that the fonts on this page are huge.
What happens is that there's a declaration on the body:
font: x-small 'lucida grande' sans-serif;
but the size in that property is ignored. The coma between the font families is missing, so that should be invalid.
Firefox 2/3, Opera 9.6/10, IE7, and WebKit all do still consider the size in the invalid property.
I guess bug 441469 regressed it.
"x-small 'lucida grande' sans-serif'" does not conform to the grammar for the 'font' property's value, so the entire declaration is invalid. I don't see anything in CSS2.1 that permits us to try to pull a valid font-size declaration out of the wreckage.
That said, perhaps it should be done for compatibility, but then we have a spec problem.
there's nothing in css3-fonts to change what I said in comment #1.
While Firefox 3 renders both lines of text in the same size, in 3.1/3.2 builds they are different. I have to agree with Zack here, I think the 3.1/3.2 behavior looks like correct error handling, the entire font property is thrown out.
(In reply to comment #1)
> "x-small 'lucida grande' sans-serif'" does not conform to the grammar for the
> 'font' property's value
I assume you mean that's because "'lucida grande' sans-serif" does not
conform to the grammar for 'font-family'? But why exactly? I don't see
anything in 15.3 that forbids quoting just parts of the value.
To make the example simpler: why is "font-family: 'lucida' grande"
invalid per 15.3?
This is why "font-family: 'lucida' grande" is invalid:
# If an unquoted font family name contains parentheses, brackets, and/or
# braces, they must still be escaped per CSS grammar rules. Similarly,
# quotation marks (both single and double), semicolons, exclamation marks,
# commas, and leading slashes within unquoted font family names must be
# escaped. Font names containing any such characters or whitespace should
# be quoted.
It needs to be written either
font-family: \'lucida\' grande;
font-family: "'lucida' grande";
I'm not sure whether we get this perfectly right though.
Yes, if I wanted to include those characters in the value I would need
to quote them as the spec says. What I was trying to say is that
font-family: 'lucida' grande;
should be equivalent to
font-family: lucida grande;
It seems to follow the POLA, and the spec is ambiguous on this IMO.
According to the grammar, 'expr' can have multiple 'term's,
I don't see any text regarding token types for 'font-family' in 15.3
except for <generic-family> which it says must be unquoted (ie IDENT),
so I think we should parse <family-name> as [ STRING || IDENT ]
The grammar only expresses some of the syntax constraints. The prose in comment 5 seems clear enough to me (that our behavior is correct).
I pinged the CSS committee and was told that the intent is:
<family-name> : STRING | IDENT+
with "the further restriction that <family-name> cannot be one of the single IDENTs serif, sans-serif, cursive, fantasy, monospace, inherit, default or initial." (in other words, <generic-family> and inherit/default/initial win over this production). See http://lists.w3.org/Archives/Public/www-style/2009Apr/0325.html and replies.
This rule prohibits 'font-family: "lucida" grande'; if there's a string, there may be only one token. Based on this I'm closing this bug report as INVALID. If you can make a case for allowing the looser syntax for web compatibility, though, we're listening.
*** Bug 499426 has been marked as a duplicate of this bug. ***
*** Bug 510463 has been marked as a duplicate of this bug. ***