sass / libsass-net

A lightweight wrapper around libsass
MIT License
94 stars 35 forks source link

Wrong encoding? #24

Closed geniuscodemonkey closed 8 years ago

geniuscodemonkey commented 9 years ago

Hi,

When I have a "content: '\e003';" in scss the file gets converted to "content: "";" instead of keeping the "\e003" ascii value. This is using the CompileFile function. KR

MK

geniuscodemonkey commented 9 years ago

have a scss file of... @import 'mixin';

a {
@include pseudoFontIcon('\e003'); }

with a mixin defined as ...

@mixin pseudoFontIcon($content) { content: $content; }

outputs a css of...

@charset "UTF-8"; a { content: ""; }

aviatrix commented 9 years ago

@geniuscodemonkey Thanks for the report, will look into it as it might be libsass bug and not libsass-net related. Will let you know as soon as possible

Risord commented 8 years ago

Hi I suffer for same problem. Some testing: .myClass { content: "\f000"; } -> "\f000" //Right

$my-variable: "\f000"; .myClass { content: $my-variable; } -> ""

And on both way if using actual utf-8 character its also leads to "". In my case its fine to get eather ascii representation \f000 or actual utf character .

driekus77 commented 8 years ago

The sassc command-line tool from native C/C++ libsass is having the same encoding issue.

https://github.com/sass/libsass/issues/1235 looks into this... which is a dupplicate of: https://github.com/sass/libsass/issues/1231 So it should be fixed in the following libsass (C/C++) release?

madskristensen commented 8 years ago

I think it's the same issue with the CompileFile function, but I can repro it with this:

content: "✔";

which generates this:

content: "✔"; 

I don't think it's a libsass issue since this issue doesn't seem to repro in the node module. Perhaps the CompileFile function should take a System.Text.Encoding parameter?

darkthread commented 8 years ago

Unicode Test

I found that libsass-net can't handle Unicode characters well. Is it a issue from libsass?

rogerfar commented 8 years ago

Is there a work around for this issue? Right now font-awesome or bootstrap are not even usable, it's all a encoding mess.

geniuscodemonkey commented 8 years ago

Sorry, I couldn't find a work around for this;  but I didn't look to closely at the GitHub code. I ended up using another library (I can't remember what it was though and I don't have the code handy anymore)

Sent from my Samsung Galaxy smartphone.

-------- Original message -------- From: Roger Versluis notifications@github.com Date:26/11/2015 18:10 (GMT+00:00) To: darrenkopp/libsass-net libsass-net@noreply.github.com Cc: geniuscodemonkey mkillgallon@killersoftware.co.uk Subject: Re: [libsass-net] Wrong encoding? (#24)

Is there a work around for this issue? Right now font-awesome or bootstrap are not even usable, it's all a encoding mess.

— Reply to this email directly or view it on GitHub.

am11 commented 8 years ago

The spec test https://github.com/sass/sass-spec/tree/master/spec/libsass-closed-issues/issue_1231 (for sass/libsass#1231) is passing with LibSass.NET master, so this should be fixed with the upcoming release.

test.scss

@mixin pseudoFontIcon($content) {
    content: $content;
}
a:before {
  @include pseudoFontIcon('\e003');
}

C# code:

var options = new SassOptions
{
    InputPath = "path\\to\\my-test.scss"
   // Note: here if we add another option:
   //
   // OutputStyle = OutputStyle.Compressed
   //
   // compiler will not produce @charset "UTF-8"; statement in
   // the output but instead use the byte-order-mark (BOM). This
   // is totally fine, because either way browser will show the
   // right thing.
};

var sass = new SassCompiler(options);
var result = sass.Compile();

File.WriteAllText("path/to/styles.css", result.Output); // IO writes are now handled by consumer
                      // (probably later in a separate extension package: LibSass.NET.Extensions)
                       // either way no encoding is necessary to be passed to WriteAllText method

Do - verify the styles.css in browser. Don't - rely on the visibility in text editor.

.. because the rendered Unicode chars are different than \e escaped ones. If (for some unrelated reason) we do want that the compiler must produce the visible \e003, it is possible by using quoted interpolation (like happening in aforementioned spec fixture):

@mixin pseudoFontIcon($content) {
    content: #{"\""+$content+"\""};
}
a:before {
  @include pseudoFontIcon(\e003); // without single/double quotes here
}

The important thing is, while both outputs looks different in text editor, they produce same effect when rendered by the browser.

aviatrix commented 8 years ago

Since it's fixed, i'm closing the issue.