Investigate when (not) to insert the double linefeed

[mgol]

Note: this will probably be fixed by ruby sass itself!

Libsass & Ruby Sass in many cases insert a double linefeed, e.g. after a block. There are differences in various edge cases, though, like what I reported in #1028. This requires investigation to what is the exact algorithm to generate those newlines.

An issue opened by advice from @mgreter.

[mgol]

Spec submitted: sass/sass-spec#299

[mgreter]

I think I got a little further here (I actually missed that @support is indented in your example)

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

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

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

Ruby sass will output this:

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

So it seems that ruby sass adds indentation only if the original block contains some other declarations. It is quite likely that this also indicates when to insert a double linefeed!

[mgreter]

@xzyfer this is basically all happening in cssize. The @support rule is bubbled up and should remember from where it bubbled up to get the right indentation in the output. It should set the "tabs" option accordingly, but I was not able to implement it in cssize. Maybe you can give some hints how the whole thing works (like what does debubble do, what are Bubble statements, etc). I think this will be the key to get the last output bits in sync with ruby sass!

[xzyfer]

cssize is pretty much a one to one port of the sass cssize.rb. I'm very hesitant to make changes to cssize that cause it to diverge from the reference implementation until we have parity.

[xzyfer]

@chriseppstein has suggested this may be a bug in the Ruby Sass implementation. We'd be better served fixing the issue on their end.

[mgreter]

Is there any update on this issue?

[xzyfer]

@chriseppstein has confirmed the double newlines are a bug in Ruby Sass but a low priority. We'll wait for this to addressed upstream.

[xzyfer]

I don't think there is anything we need to do here. These new lines have no semantic meaning. Sass spec normalises new lines which means this spec is currently passing.

[mgol]

These new lines have no semantic meaning.

That's true but the idea was that libsass should match Ruby Sass output even with regards to whitespaces, wasn't it?

[xzyfer]

Ideally yes. In reality some things aren't possible without matching the
Ruby Sass data structures which some times isn't practical in c++. In this
case the duplicate new lines happen some what unpredictably. With matching
the Ruby Sass AST we'd never get it 100% correct.
On Mar 21, 2016 9:49 AM, "Michał Gołębiowski" [email protected]
wrote:

These new lines have no semantic meaning.

That's true but the idea was that libsass should match Ruby Sass output
even with whitespaces, wasn't it?

—
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub
#1030 (comment)