Erroneous space inserted in { property: value-as-digit\9; }

[atdrago]

Adding a \9 after a property value that ends in a digit adds an erroneous space before the \.

For example,

div { opacity: 1\9; }

Should output

div { opacity: 1\9; }

But instead outputs

div { opacity: 1 \9; }

Ruby sass compiles the value without the inserted space.

[xzyfer]

Thanks for the report @atdrago. Could you please also provide a test case in sass-spec? Here's a good example of one sass/sass-spec#315.

@mgreter this is a regression from 3.1.0. I'll do a bisect shortly.

[atdrago]

Thanks for the response, @xzyfer. Added a PR sass/sass-spec#327

[xzyfer]

Specs added sass/sass-spec#331. Turns out this regression is more server then first suspected.

div { 
    opacity: 1\9;
    width: 500px\9;
    color: #f00\9\0\;
}

Ruby Sass

div {
  opacity: 1\9;
  width: 500px\9;
  color: #f00\9\0\;; }

Libsass 3.1.0

div {
  opacity: 1\9;
  width: 500px\9;
  color: #f00 \9\0\;; }

Libsass 3.2.0-beta.5

div {
  opacity: 1 \9;
  width: 500px \9;
  color: #f00\9\0\\; } // extra /

[xzyfer]

@mgreter I've started a WIP #1111 before I noticed the other error cases.

I'm not tied to this PR so if you think you can fix this quickly go for it. I'm really want to ship the final beta asap 🎉

[mgreter]

IMO it's related to our way to parse every list as a space or comma separated list. Not sure how ruby sass handles this internally. Since this syntax is used as a IE css hack, we could make sure that the way we output it currently will still be valid for those old IE UAs. If that is the case, it is IMO not a real blocker for the next release. We do allow escaped sequences in identifiers (static_value), but all the above cases are not valid identifiers. IMO a hotfix for certain use-cases is possible, but to support this correctly we need the non-spaced list parsing (which is IMO not possible in the scope of the current beta).

[xzyfer]

IMO it's related to our way to parse every list as a space or comma separated list.

This is true.

IMO not a real blocker for the next release

Assuming what we output still has the desired affect I also agree. I'll make sure the "hack" is still repected with the space.