Active passing spec tests after PR 1249

[mgreter]

Passing quite some spec tests after the big refactoring 🎉

List of fixed open issues:

• CSS comments inside selectors yields invalid top-level expression libsass#941
• Dynamic division with interpolation not compatible with libsass libsass#948
• Error with & selector interpolation in @at-root blocks libsass#1043
• libsass preserves new lines in nested style more often than Ruby Sass does libsass#1061
• & + '' needs to be wrapped in parentheses libsass#1170
• invalid operands for multiplication - once again libsass#1207
• Regression in parsing @at-rules libsass#1214 *
• @debug intentionally sometimes produces different output that the css libsass#1240
• Variables in at-directives should not be evaluated libsass#1253
• Error: invalid selector after & libsass#1260
• Custom at-rules causes LibSass an error but not the Ruby version of Sass libsass#1263 *
• Error parsing interpolated value libsass#1277
• @at-root inside Loops will be ignored libsass#1285
• @at-root with dynamic selector doesn't work libsass#1297
• Interpolation error in classes starting with - libsass#1301
• Selector replace doesn't respect specificity libsass#1303
• Cannot @debug null libsass#1336

[xzyfer]

Please pull out the failing tests for now. Otherwise 🚢

[mgreter]

@xzyfer it seems that this CI runs against ruby sass!? That's why it is failing the 3 test cases we already discussed. Or am I seeing ghosts? Not sure how to handle this, but not having any specs because of minor discrepancies is the worst solution IMHO ... and I really don't want to replicate every "broken" behavior of ruby sass in libsass, because libsass IMO produces the correct output!

[xzyfer]

it seems that this CI runs against ruby sass

Yes this is on purpose. Spec should not fail on Ruby Sass, it would defeat the purpose of a Sass language spec if the reference implementation couldn't pass it.

That's why it is failing the 3 test cases we already discussed

We discussed leave the failing tests out for now whilst I chase up the Ruby team to address this on their end.

I really don't want to replicate every "broken" behavior of ruby sass in libsass

I understand, but Sass is about the Sass language, not LibSass. The goal is for other Sass implementors to be able to run their Sass implementation against sass spec to verify "correctness". Correct is currently defined as doing what Ruby Sass does.

libsass IMO produces the correct output!

I also agree but we can't change a spec's output for every future implementation's quirks.

---

The long term solution here is to change Sass spec from exact string comparison (it's already does some whitespace normalisation so it's "exact") to semantic comparisons on the output CSS's AST. This has been discuss with the Ruby Sass team and their onboard, it just requires resources.

---

As discussed in Slack, lets leave the failing tests out. We'll try to solve this issues for good.

[xzyfer]

I keep hitting close instead of comment. I have butter fingers today.

[mgreter]

In this case we should change ruby spec runner to "normalize" /,\s*/ to , in compressed mode ...

[xzyfer]

It's worth a shot. We need to be really careful with naive replacements so we don't mess with quoted strings and such.

To be safe we need to compare AST. I'm trying to get someone from the community to maintain Sass spec and take on these features/issues.

[mgreter]

I just saw that I already implemented something for this case (and it seems I also did it for the ruby spec runner). You actually can add an empty file named expected_outstyle.clean to activate the previousely used white-space cleaning. Looks like we can activate those tests afterall :smile;