145190 - espn.go.com - no recovery on CSS parse error for missing curly brace, subsequent rules not applied

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: English US, defect)

Description

[Dave]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0+) Gecko/20020516
BuildID:    2002051608

In the URL above, a browser sniffer JavaScript writes a link to an appropriate
style sheet.  For Netscape/Mozilla, this one:
http://espn.go.com/insertfiles/css/mlb/font_nn.css
Here is the W3C validation output for this style sheet:
http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fespn.go.com%2Finsertfiles%2Fcss%2Fmlb%2Ffont_nn.css&warning=1&profile=css2
There are two parse errors:
* Line: 93
  Parse error - Unrecognized : }
* Line: 395 Context : .NEWSNFL
  Parse Error - .NEWSSUBNFL { font-family: times; font-weight: bold; font-size:
14px;}
The second parse error turns out to be a missing right curly brace ("}").
The two most important rules for the layout of this page (and all pages based on
this template) are .STATS and .SCHEDbold -- located below the 2nd parse error. 
When I make a local copy of the files (HTML and CSS) and correct the first error
on line 93 (removing the extra "}" ), Mozilla displays the page exactly the same
as it did before (incorrectly).  It is only when I fix the missing "}" error
(even if I don't fix the first) that the page displays correctly (that is,
Mozilla applies the .STATS and .SCHEDbold rules).
The .STATS rule is the 3rd rule listed after the missing "}", and the .SCHEDbold
rule occurs a great deal below the missing "}".  I think Mozilla ought to be
able to recover from this error after at most the next occurrence of a closing
brace ("}").  In that case both the .STATS and .SCHEDbold rules would be
processed and applied to the page's layout, making the best of a bad situation.
Both IE 6 and Netscape 4.79 display the local copy (and the online copy) of the
page correctly _before_ I correct either error.  In my local copy of the HTML, I
hardcode the link to the style sheet so that the same one is used in any
browser.  The effect is still observable when I include the CSS file's contents
inline in a style tag (instead of using a link).

Reproducible: Always
Steps to Reproduce:
1.  Load the URL in Mozilla
2.  Observe that default serif font and default size are used in the table
instead of the styles from rules .STATS and .SCHEDbold.

Actual Results:  Mozilla does not (is not able to?) apply the .STATS and
.SCHEDbold rules.  (No recovery from parse error prevents it?)

Expected Results:  Mozilla makes the best of bad CSS and recovers from the
missing curly brace error as soon as it can, and salvaging subsequent rules
including .STATS and .SCHEDbold (both of which occur far enough below the
missing "}" error to be salvaged).

Comment 1

[Alfonso Martinez]

Isn't it better to fix the broken css file?

Comment 2

[Boris Zbarsky [:bzbarsky]]

Ths CSS standard is very clear about cases like this.  Anything that is not
recognized as a valid rule must be ignored.  Failure to do that is a gross
violation of the standard and is bad for forward compatibility with future
revisions.

In other words, there is no "bad css", only "css this browser does not
understand but that may mean something to future browsers".

IE6 and NS4 are blatanly wrong here.

Comment 3

[Dave]

I understand your point, and if we go with your diagnosis, and I have already
emailed ESPN.com to ask them to fix their style sheets.
However, I read the CSS2 specification section on when to ignore rules because
of parsing errors, and I did not find this case.  It didn't say "Anything that
is not
recognized as a valid rule must be ignored."  It said "In some cases, user
agents must ignore part of an illegal style sheet."  It lists the following
cases:  "Unknown properties", "Illegal Values", and "Invalid at-keywords". 
Boris, do you know of another document in which you would find the rule that
anything not recognized as a valid rule must be ignored"?  If I had known about
such a rule, I would not have filed this bug, but my only source was the following:
http://www.w3.org/TR/REC-CSS2/syndata.html#parsing-errors

Comment 4

[Boris Zbarsky [:bzbarsky]]

This actually falls under "invalid properties", I think.  But I also can't
locate the part that talks about invalid selectors, so I know I'm missing
something...

Temporarily setting QA to Ian to get that information.

Comment 5

[Dave]

Oh, I think I know what the issue is.
When the missing right curly brace never appears, as far as the parser is
concerned, all subsequent rules belong inside whatever scope was never closed
(nested rules, I guess).  I just didn't realize that nested rules exist until I
looked closer at an example in the spec.  I guess the reason Mozilla apparently
didn't apply the rules wasn't was not so much that the rules were invalid as it
was that they no longer applied as intended because they were accidentally
nested in the scope of the rule the author forgot to close, right?

Comment 6

[Boris Zbarsky [:bzbarsky]]

Basically, yes. They were parsed as property:value pairs and that failed....

Comment 7

[Hixie (not reading bugmail)]

removing myself from qa as you resolved the problem :-)

Comment 8

[Bob Clary [:bc] (inactive)]

->evang500

Comment 9

[Bob Clary [:bc] (inactive)]

Mine! Mine! All Your Base Belongs to Me!

Comment 10

[Bob Clary [:bc] (inactive)]

we no longer get the nn stylesheet (instead get an IE one) the page appears
redesigned and looks fixed to me.