Loss of spaces in interpolated selectors

[mgol]

The following:

h1:nth-of-type(#{2 + 'n + 1'}) {
    color: red;
}

is transformed by libsass to:

h1:nth-of-type(2n+1) {
  color: red; }

As you can see, spaces around the + are lost. Ruby Sass (3.4.5) preserves them.

[mgol]

That's not a very important issue, obviously. It's just that I'm currently in a process of trying to migrate from Ruby Sass so I'm comparing output of both tools and those minor differences make it a little harder to find true differences.

Is normalizing such stuff in scope of libsass code and Sass spec?

[xzyfer]

Thanks for reporting this! Normalising these things is certainly within the scope of sass-spec.

Could you please add a spec in https://github.com/sass/sass-spec ?

Here's an example of a good spec PR for reference https://github.com/sass/sass-spec/pull/89/files

[mgol]

Done: sass/sass-spec#113

[xzyfer]

This will require refactoring to how we handle combinators. Conveniently it's the same refactoring required for #452. My feeling is these two will be happen at the same time.

[mgreter]

This actually seems to be simpler than expected, as it probably has nothing to do with interpolation

h1:nth-of-type(2n + 1) {
    color: red;
}

This shows the same difference between ruby sass and libsass. For me it looks like ruby sass parses the 2n + 1 as a static value, since I saw pretty much the same thing with other static values.

IMO we should add some rules to static value parsing to include the plus sign when it's safe. IMO @xzyfer has done some work with static value parsing. IMO we need something like this:

sequence<
  alternatives <
    identifier,
    static_string
  >,
  zero_plus < sequence<
    optional_spaces,
    exactly < '+' >,
    optional_spaces,
    alternatives <
      identifier,
      static_string
    >
  > >
>(src);