-
Notifications
You must be signed in to change notification settings - Fork 462
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Binary operators adjacent to interpolations produce incorrect output and/or errors #1728
Comments
I wonder if this is intended behaviour or just some byproduct of Ruby Sass implementation... |
Does this matter? We need to do what Ruby Sass does. |
Spec added sass/sass-spec#606 |
I think @saper is correct in that it was not an intentional decision and rather a byproduct of Ruby SASS not having a clear specification. From a language design perspective, this behavior is terrible. The output is unexpected, use cases are practically non-existant, and it means accurate syntax coloring is impossible without analyzing the AST. Perhaps an issue should be opened upstream to have it reviewed, and possibly improved as a breaking change in a future version. Ideally the only operator that would act this way is dash, and only when there is no whitespace separating the interpolation and the identifier.
Wishful thinking, perhaps. |
It would be good to @nex3's thoughts. |
This was, more or less, intentional. It's an artifact of the long-ago move from explicitly invoking SassScript (e.g. I agree that this is a gross status quo, though. This is why I filed sass/sass#1778 to track the removal of this bizarre behavior. It'll be gone in 4.0. |
@nex3 Thank you for the explanation. sass/sass#1778 looks like a move in the right direction, for sure. |
Thank you for the explanation @nex3 ! Regarding 4.0 I've had a brief look at https:/sass/sass/milestones/4.0 and I was wondering is there any chance we could have a more formal (BNF?) specification of Sass 4.0? Would simplify greatly testing and building new interpreters. |
Writing a full specification is a huge amount of effort. It's something I'd like to do at some point in the future, but currently design and implementation take up all my available time. |
Based on the comment by @andrew-skybound "#{a}+b // this should concatenate like two ordinary strings", I believe I am seeing the same problem. To start, here are the details of my environment, system, etc. to as great as detail as I can provide (let me know if there is something more I should mention): OS X Yosemite 10.10.5 I was seeing some odd behavior in the output of my scss files processes by node-sass.
The problem is that div.still-wrong was expected to have a color property of JUNK-appended-value, but it just leaves off the 'appended-value' part. I know how to fix it and that is by just placing a space between the variables, strings, and operators like in the ANOTHER_VAR example. This works, but I don't understand what is actually wrong. I have been chasing this bug for some time and just stumbled across this issue conversation. I'm still lost as to why this is an issue though. Am I seeing the same problem? If so, can anyone do me a huge favor and explain what is going on here? |
@gedkott The example you posted works just fine for me (the value of the last declaration comes out |
This issue is somewhat complicated so I'm first going to explain how I have observed Ruby SASS to work with respect to operators that appear adjacent to interpolation expressions, followed by the tests and results.
Background
In SASS, the behavior of binary operators changes when they are adjacent to an interoplation expression. They produce a kind of delimited string-concatenation operation, where the delimiter is the operator itself, and they cause the entire surrounding sequence of terms to become part of a single, unquoted string.
This behavior is specific to interpolation expressions; unquoted strings produced by
unquote()
do not operate in this way:This behavior is consistent for all numeric, comparison, and logical binary operators. But here is the interesting part: when another binary expression is concatenated to an interpolation expression in this way, the entire expression is evaluated according to operator precedence even though concatenation does not produce a numeric result. Consider these examples:
Take special notice of example 3, 4, and 5: the order in which these terms are being evaluated is different than it would be if the same operators were used for a numeric expression. Sequential numeric expressions with operators of the same precedence are usually evaluated left-to-right, but here, the concatenation always happens last even when it is on the left.
Finally, whitespace around the operator is preserved in the output as either zero or one space:
Tests
Here is a complete test suite that should cover everything. I have categorized the tests:
(a) tests the spacing around numeric operators when the interpolation expression is on the left
(b) tests the spacing around numeric operators when the interpolation expression is on the right
(c) tests numeric operator precedence when the interpolation expression is on the left
(d) tests numeric operator precedence when the interpolation expression is on the right
(e) tests comparison operator precedence
Logical operators (and/or) have been omitted for brevity but exhibit the same behavior.
Ruby SASS Output: (3.4.19)
Now, because of the way Libsass incorrectly interprets these operators, many of these tests cause errors to occur. Here is the same test as above with the declarations that Libsass cannot yet handle commented out:
It's worth noting that the "e" tests fail beacuse of #1727.
Here is the output Libsass produces. Only c02, c10, and c14 are correct:
Libsass Output (3.2.5):
The text was updated successfully, but these errors were encountered: