Regression in the way broken font property values are parsed




CSS Parsing and Computation
9 years ago
8 years ago


(Reporter: Sylvain Pasche, Assigned: zwol)


({regression, testcase})

regression, testcase

Firefox Tracking Flags

(Not tracked)



(1 attachment)



9 years ago
Created attachment 365531 [details]

If you open 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:

I guess bug 441469 regressed it.


9 years ago
Assignee: nobody → zweinberg

Comment 1

9 years ago
"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

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

Comment 3

9 years ago
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?

Comment 5

9 years ago
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,
including STRINGs:

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

Comment 8

8 years ago
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 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.
Last Resolved: 8 years ago
Resolution: --- → INVALID
Duplicate of this bug: 499426
Duplicate of this bug: 510463
You need to log in before you can comment on or make changes to this bug.