481502 - Regression in the way broken font property values are parsed

Status: RESOLVED INVALID

(Core :: CSS Parsing and Computation, defect)

Description

[Sylvain Pasche]

Attachment: testcase

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:

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.

Regression range:
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-08-10+00%3A00&enddate=2008-08-11+04%3A00

I guess bug 441469 regressed it.

Comment 1

[Zack Weinberg (:zwol)]

"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.

Comment 2

[Zack Weinberg (:zwol)]

there's nothing in css3-fonts to change what I said in comment #1.

Comment 3

[John Daggett (:jtd)]

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.

Comment 4

[Mats Palmgren (inactive)]

(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?
http://www.w3.org/TR/CSS21/fonts.html#font-family-prop

Comment 5

[Zack Weinberg (:zwol)]

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;

or

  font-family: "'lucida' grande";

I'm not sure whether we get this perfectly right though.

Comment 6

[Mats Palmgren (inactive)]

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,
including STRINGs:
http://www.w3.org/TR/CSS21/grammar.html

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 ]

Comment 7

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

The grammar only expresses some of the syntax constraints.  The prose in comment 5 seems clear enough to me (that our behavior is correct).

Comment 8

[Zack Weinberg (:zwol)]

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.