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

RESOLVED INVALID

Status

()

RESOLVED INVALID
5 years ago
5 years ago

People

(Reporter: wycats, Unassigned)

Tracking

(Blocks: 1 bug, {testcase})

29 Branch
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
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.

Updated

5 years ago
Component: Untriaged → CSS Parsing and Computation
Keywords: testcase
OS: Mac OS X → All
Product: Firefox → Core
Hardware: x86 → All
Summary: The UI of a blog I read is bad compared to Chrome → Gecko treats certain CSS parsing errors (missing quotes or commas in CSS values) more strictly than Chrome/Safari (Blink/Webkit)
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.
Flags: needinfo?(simon.sapin)
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
Flags: needinfo?(simon.sapin)
Blocks: 962671
You need to log in before you can comment on or make changes to this bug.