Interpolation Issue - Combining Values

[grayghostvisuals]

I have a user on my project that filed an issue in regards to interpolation using libsass w/gulpsass so I'm curious if this is a bug within libsass' interpolation as the current method I use works just fine according to the docs and compiling with Ruby.

Here's the code that seems to be the problem…

@function context-calc($scale, $base, $value) {
  @return ($scale/$base) + $value; // was @return ($scale/$base)#{$value};
}
@function measure-margin($scale, $measure, $value) {
  @return ($measure/$scale) + $value; // was @return ($measure/$scale)#{$value};
}

As you can see the commented lines were the original lines that worked just fine when compiling with Ruby otherwise libsass was giving this font-size: 32 rem as a result.

[grayghostvisuals]

anyone willing to take a look at this yet? + @akhleung @nex3

[HamptonMakes]

Yeah definitely looks like an issue with interpolation.

[grayghostvisuals]

Thanks for taking the time to look Hampton Inn & Suites ;) 🍻

[malrase]

I'm in the process of writing a test and put the code into a gist:
http://sassmeister.com/gist/ed4788de313bcabe9f68

(That should be using Sass 3.4)

Is that the desired interpolation behaviour? I can see how the libsass result:

.test {
  margin: 10 1px 2px 3px; }

is not correct.

However, I guess I'd expect Sass 3.4 to give a result closer to

.test {
  margin: 101px 102px 103px; }

[grayghostvisuals]

@malrase Results have a separation. I get this reported to me via libsass users… font-size: 32 rem Notice the gap between the last digit and the string “rem”

[malrase]

Ah! I see what you mean. It's difficult to test right now, unfortunately.

http://sassmeister.com/gist/7b8f1f58a2b356aac923

The above will be the test when we can test it.

@hcatlin can you remove the "needs test" tag from this while we get it sorted out.

[xzyfer]

I've moved this to 3.2 because it's appears to be non-insignificant fix and 3.1 is just about ready for release.

[KittyGiraudel]

Adding to the discussion: appending a unit as a string is a very poor way of converting a unitless number to a length since it results in having a string instead of a number, preventing any further calculation.

[mgreter]

IMHO this is a pretty difficult issue since it involes parse_list, which we currently always expect to be at least space separated. I have added a debugger.hpp file which contains a debug_ast function:

input:

foo { bar: (10/10)#{rem}; }

output:

foo { bar: 1 rem; }

debug_ast:

Block 0x2630200 0
 Ruleset 0x22652c0 0
  Selector_List 0x26302e0 - -
   Complex_Selector 0x26e6300 - - -> { } <> X < >
    Compound_Selector 0x23993c0 - - <> X < >
     Selector_Reference 0x2991a20 @ref 0
   -Complex_Selector 0x26e61a0 - - -> { } <> X <>
   - Compound_Selector 0x23992d0 - - <> X <>
   -  Type_Selector 0x2991980 <<foo>> - <> X < >
  Declaration 0x2b27dc0 0
   prop: String_Quoted : 0x26e63b0 [bar] < > X <>
   value: List 0x2b27cf0 [Space] [delayed: 0]  [interpolant: 0]
   value:  Binary_Expression 0x26e65c0 [11]
   value:   left:  Textual  [NUMBER]0x26e6460 [10]
   value:   right: Textual  [NUMBER]0x26e6510 [10]
   value:  String_Schema 0x2b30d90 4 {has_interpolants}
   value:   String_Quoted : 0x26e6670 [rem] {delayed} <> X <>

As you can see this gets parsed as a space separated list, and that's the reason why it fails! IMHO this needs to be parsed and render completely different, so this doesn't look like an easy fix!

Also consider this example:

input.scss

// interpolated-urls
fudge { walnuts: blix"fludge"#{hey now}123; }

ruby sass output:

fudge { walnuts: blix "fludge"hey now123; }

libsass output:

fudge { walnuts: blix"fludge"hey now123; }

The differences are very subtile and I have no idea yet what the actual rule behind it is (and if it actually makes sense or if it should be considered a ruby sass bug).

[xzyfer]

Agreed I've looked into this a couple times and it's non trivial. Ruby Sass handles this my having a separate SassScript parser.

I also think our approach to "everything is a list" is a bit overzealous and is the cause some tricky bugs.

[mgreter]

IMO we should re-scope this to Milestone 3.3

[xzyfer]

👍
On 4 Mar 2015 08:43, "Marcel Greter" [email protected] wrote:

IMO we should re-scope this to Milestone 3.3

—
Reply to this email directly or view it on GitHub
#442 (comment).