Persona is no longer an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 481502 - Regression in the way broken font property values are parsed
: Regression in the way broken font property values are parsed
: regression, testcase
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: Zack Weinberg (:zwol)
: Jet Villegas (:jet)
: 499426 510463 (view as bug list)
Depends on:
Blocks: 441469
  Show dependency treegraph
Reported: 2009-03-04 13:59 PST by Sylvain Pasche
Modified: 2009-08-14 07:28 PDT (History)
13 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

testcase (362 bytes, text/html)
2009-03-04 13:59 PST, Sylvain Pasche
no flags Details

Description Sylvain Pasche 2009-03-04 13:59:21 PST
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.
Comment 1 Zack Weinberg (:zwol) 2009-03-04 14:35:31 PST
"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) 2009-03-04 14:36:55 PST
there's nothing in css3-fonts to change what I said in comment #1.
Comment 3 John Daggett (:jtd) 2009-03-04 15:18:08 PST
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 (:mats) 2009-03-05 05:04:26 PST
(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 Zack Weinberg (:zwol) 2009-03-09 16:30:55 PDT
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.
Comment 6 Mats Palmgren (:mats) 2009-03-09 17:53:39 PDT
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 ]
Comment 7 David Baron :dbaron: ⌚️UTC+9 (busy until November 7) 2009-03-09 18:00:51 PDT
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) 2009-04-22 09:21:33 PDT
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.
Comment 9 David Baron :dbaron: ⌚️UTC+9 (busy until November 7) 2009-06-20 13:44:46 PDT
*** Bug 499426 has been marked as a duplicate of this bug. ***
Comment 10 David Baron :dbaron: ⌚️UTC+9 (busy until November 7) 2009-08-14 07:28:36 PDT
*** Bug 510463 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.