variable interpolation causes additional string escaping

[kbullaughey]

I originally posted this issue to node-sass, but as pointed out there, this seems to be an issue in libsass.

It seems when a string involves string interpolation, slashes that appear elsewhere in the string, say for unicode sequences, end up getting slashed out. This did not used to be the case.

For example:

li:before { content: "#{'y'}\00a0"; }

Will become

li:before { content: "y\\00a0"; }

Instead of:

li:before { content: "y\00a0"; }

I confirmed this was not a node-sass issue by reproducing it with sassc. Older versions of node-sass using older versions of libsass do not cause this unexpected behavior.

[xzyfer]

I've confirmed this is a regression the 3.2.0-beta.5. A git bisect shows the regression was introduced in 7877cfa /cc @mgreter

[xzyfer]

Thanks for the report @kbullaughey. Could you please submit a sass-spec for this issue?

This is a good example to follow https://github.com/sass/sass-spec/pull/330/files

[mgreter]

This is pretty strange behavior by ruby sass IMO:

foo { bar: "x\79"; } // => x\79
foo { baz: "#{x}\79"; } // => xy
foo { bar: "x\a"; } // => x\a
foo { baz: "#{x}\a"; } // => x\a

[xzyfer]

@mgreter I agree it's strange for Sass to treat \79 as a hex value, and cast it back to y.

@chriseppstein @nex3 is this known issue/feature? I see no mention of it in the sass documentation , or an existing bug report.

[nex3]

Sass parses strings according to the CSS spec, including resolving escape sequences. It doesn't keep around the original representation of strings, so when emitting them back to CSS it makes decisions about whether to emit an escape or a literal character independent of the original format. In general it tries to emit the literal character except in cases where that would break parsing, like newlines or quotes. This behavior sometimes weirds people out, but I haven't seen any evidence that it causes problems for browsers.

The reason this varies based on interpolation has to do with an unrelated optimization in Ruby Sass. Most properties in a stylesheet, even one using Sass, are static; they don't involve any variables or other special SassScript stuff. When Sass detects a property that it can prove is static, it doesn't even parse it; it just stores its original value as a string and emits that to the stylesheet. This means that artifacts that would usually be removed in the parse-and-emit process can remain if nothing dynamic is going on. Libsass shouldn't feel obligated to duplicate this behavior; as long as the output is semantically identical, it's fine.

[xzyfer]

Thanks for the information @nex3.

Libsass recently implemented the static value optimisation as well. Without it we found parsing and emitting static values resulted in too many unpredictable subtle differences. I expect any implementation attempting completely mimic the Ruby Sass output, as required by sass-spec, will need to have a similar optimisation.

[nex3]

It would be nice to have a way to verify semantic equivalence without byte-for-byte comparisons :-/.

[xzyfer]

Specs added sass/sass-spec#340

[realityking]

Small FYI, this breaks Bootstrap as it's used in the Breadcrumb separator.

[xzyfer]

Thanks for the info @realityking /cc @mdo

[cvrebert]

@xzyfer Protip: @mdo doesn't maintain bootstrap-sass. Please let someone on the Bootstrap Sass Team know next time, or file a bug in bootstrap-sass.

[karolyi]

+1