Incorrect @supports indentation

[mgol]

The following SCSS:

@mixin will-change() {
    @supports (will-change: transform) {
        will-change: transform;
    }
}
div {
    a {
        top: 10px;
        @include will-change();
    }
}

libsass from node-sass 3.0.0-beta.4 turns into:

div a {
  top: 10px; }

@supports (will-change: transform) {
  div a {
    will-change: transform; } }

Latest Ruby Sass gives:

div a {
  top: 10px; }
  @supports (will-change: transform) {
    div a {
      will-change: transform; } }

[mgreter]

We are aware of the newline differences, but currently we are not planning to address these anytime soon, since they are very easy to spot in diff tools and you probably can tell your diff tool to just ignore them. If you want, please open a more generic issue that double linefeeds differ from ruby sass. I did not understand the logic behind what ruby sass does there, as it is not really consistent while libsass is pretty consistent (therefore the diffference). Once to logic is clear we may be able to solve it!

[mgol]

Sure, this is far from the most important issue. I just reported all I found (I periodically check on my rather large project what still stops me from migrating from Ruby Sass and report all differences) and I thought you plan to fix it eventually as you marked one of my other white-space related tickets (#593) as planned for 3.4.

[mgol]

please open a more generic issue that double linefeeds differ from ruby sass

Double linefeeds? What do you mean? The source doesn't have consecutive \n\n.

[mgreter]

The output in libsass contains a double linefeed after the div, while ruby sass does not. Ruby sass normaly does it after a block in the root, but not here. As I said, please open a more generic issue about that, since there are quite a lot of other places where this occurs. We just don't know why ruby sass does it, so we cannot really fix it!

[mgol]

OK, I opened #1030.