added a variable for \00a0 unicode character for breadcrumb

[gniquil]

When used with certain preprocessor, the "\00a0" string gets converted to "\00a0" unless it is in a variable, which shows the full string rather than an empty space on webpage. This is aimed to fix that. For reference:

http://stackoverflow.com/questions/21608762/sass-variable-interpolation-with-backslash-in-output

[glebm]

This change would need to go upstream. This repo is an automated conversion from LESS to Sass.

[orrd]

@glebm Bootstrap is claiming the problem is an issue with boostrap-sass. I suspect they may be right since it seems to only be affecting bootstrap-sass and not the LESS version of Bootstrap (as far as I know).

[cvrebert]

@orrd Please file a new bug in this repo. Include step-by-step instructions on how to reproduce the problem.

[orrd]

@cvrebert I just found this the issue is described here: sass/sass#659 ("There is currently no way in Sass 3.4 to get content: '\f107' if a variable exists anywhere as a part of that string").

It may be a SASS bug/issue, but apparently there are hacks that can be used to work-around it. Let me know if it still makes sense to file this as a new bootstrap-sass bug. I think it may only affect some versions of SASS but I don't know for sure (I believe the compilation environment I'm using is using gulp-sass 2.0.1, which I think uses node-sass 3.2.0, which I think uses libsass 3.2.5).

[cvrebert]

Okay, I can confirm that under the environment:

sassc: 3.2.1
libsass: 3.2.4
sass2scss: 1.0.3

the SCSS in question:

content: "#{$breadcrumb-separator}\00a0";

is getting compiled to

content: "/\\00a0";

which is incorrect.
By comparison, Ruby Sass compiles this code to:

content: "/ ";

which is correct (albeit not ASCII).
So this appears to be a libsass bug.

[cvrebert]

And it turns out someone has already reported this bug to libsass: sass/libsass#1115

[cvrebert]

@orrd I filed #919 to discuss this further.