961836 - Gecko treats certain CSS parsing errors (missing quotes or commas in CSS values) more strictly than Chrome/Safari (Blink/Webkit)

Status: RESOLVED INVALID

(Core :: CSS Parsing and Computation, defect)

Description

[Yehuda Katz]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.77 Safari/537.36

Steps to reproduce:

1. Go to http://enlightenedpixel.com/why-i-chose-ember-over-angular in Firefox
2. Go to http://enlightenedpixel.com/why-i-chose-ember-over-angular in Chrome
3. Compare the pages


Actual results:

Observe that the site looks bad in Firefox (all versions). Compare with the same UI in Chrome and observe that it looks good.


Expected results:

It should look good.

At least one of the issues is due to different handling of the following CSS rule:

    font-family: 'Open Sans' Verdana, Arial, Helvetica, sans-serif;

There is a missing comma after the second `'`, and Chrome treats it as two separate font names, but Firefox errors.

Another issue is the following CSS selector:

    .wpcf7 input[type="text"], .wpcf7 input[type="email]

The second selector in the list is missing a closing `"` after email. Chrome treats it as `"email"` while Firefox errors.

Comment 1

[Cameron McCormack (:heycam)]

For the first error, css-fonts-3 mentions (just below http://dev.w3.org/csswg/css-fonts/#family-name-value) an example:

  font-family: "Lucida" Grande, sans-serif;

and says explicitly that the declaration is invalid, so I think we are correctly following the spec there.

For the second error, there are two relevant things from CSS 2.1:

* In http://www.w3.org/TR/CSS21/syndata.html#parsing-errors it says

    User agents must close strings upon reaching the end of a line (i.e., before an unescaped line
    feed, carriage return or form feed character), but then drop the construct (declaration or rule)
    in which the string was found.

  We are in a rule, so it seems like we should drop only that rule.

* But it also says:

    User agents must handle unexpected tokens encountered while parsing a statement by reading until
    the end of the statement, while observing the rules for matching pairs of (), [], {}, "", and '',
    and correctly handling escapes.

  A rule set is a declaration, so we should skip until we find a closing ']' to match the opening one
  in the selector, which means we should eat up a bunch of the style sheet, until the line:

    [class*="icon-"]

I don't what the precedence of these two rules are.

css-syntax-3 should give us a better idea of what to do, but I'm having trouble following it to find the correct behaviour.  Simon?  It looks like css-syntax-3 doesn't have the "drop the rule/declaration on a bad string" behaviour, but I can't see where the "you're in an attribute selector so keep going until you find a closing bracket" is defined.

Comment 2

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

I don't see any conflict between the rules.

Tokenizing:
  [type="email]
gives
 * an opening [
 * the identifier type
 * the symbol =
 * a BAD_STRING token, which is always an error (an consumes the remainder of the line)

Then, to parse these tokens, we're parsing an attribute selector and looking for its closing ] (probably until end-of-file, though I didn't find which CSS file contains the CSS in question).

So I'm pretty sure both of our behaviors are correct per spec.