Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Sass fails to detect syntax issue with stray "" typo #946

soxofaan opened this Issue Oct 2, 2013 · 2 comments


None yet
2 participants

soxofaan commented Oct 2, 2013

Here is a simple sass file with a typo: cat style.scss:

.stuff {
    color: red;

.somethingElse {
    color: blue

CssLint detects the issue: csslint style.scss:

csslint: There are 1 problems in style.scss.

1: error at line 3, col 2
Unexpected token '""' at line 3, col 2.

But Sass does not complain and generates illegal css: sass style.scss:

.stuff {
  color: red; }

.somethingElse {
  color: blue; }

nex3 commented Oct 4, 2013

This is weird, but more or less expected, due to a confluence of factors. The root of it is that Sass tries to avoid as much as possible encoding knowledge about the specifics of valid CSS, outside of the syntax -- for example, it doesn't keep track of which properties are valid. This helps a given version of Sass remain useful as specs and browser implementations change.

The reason this is relevant here is that one of the things Sass is very liberal about is @-rules. We want to be forwards-compatible with any @-rules that are introduced in the future. Unfortunately, @-rules can have very weird syntax, so maintaining this forwards-compatibility requires us to be very liberal in what we allow in some cases.

One of the weirdest @-rules, syntax-wise, is @keyframes. It starts looking like a normal rule with a block, but the syntax inside that block is different than normal CSS syntax. You can write percentages with blocks following them, as in @keyframes whatever {50% {left: 10}}, which is a construction we see nowhere else in CSS.

To handle @keyframes' weird syntax, as well as potential future weird @-rule syntaxes, Sass has the ability to parse any old expression that you might find in a property value within a selector. This supports 50% { ... }, but also means that as far as Sass is concerned, "" .somethingElse { ... } is valid as well, which is the source of the confusion here.

I'm going to leave this issue open since we should be able to mitigate this issue by only allowing this expanded selector syntax when we're actually parsing an unknown @-rule.

@nex3 nex3 closed this Feb 4, 2014

@nex3 nex3 added a commit that referenced this issue Feb 7, 2014

@nex3 nex3 Merge branch 'revert-keyframes'
The parsing changes to @keyframes, while on the whole good, broke mixins that
included keyframes blocks. We'll figure out a better way to do this after 3.3.

See #946
Closes #1102

nex3 commented Feb 7, 2014

035c51f reverts the fix for this, which caused issues detailed in #1102. We need to find a better way to fix it.

@nex3 nex3 reopened this Feb 7, 2014

@nex3 nex3 closed this in f4b07be Mar 8, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment