Add a flag to emit ASCII-only output

[dwightjack]

I'm working with Sass 3.4.

My sass source code is:

#test
  content:  "\f000"

when parsed it got converted to:

#test {
  content: "";
}

I'm using expanded style and sass syntax. I've noticed that switching to scss works correctly, anyway my entire codebase is in sass format :(

Is there any way to preserve original content unicode string?

Thanks in advance

[quantizor]

+1, I'm facing this as well and it's causing a lot of issues because now the SCSS file gets flagged as UTF-8, even though I specifically wrote it as ASCII. Then SASS outputs a file with a BOM, which ends up in the middle of my concatenated files and causes other headaches.

[lolmaus]

now the SCSS file gets flagged as UTF-8, even though I specifically wrote it as ASCII.

That's in compliance with the CSS Syntax Module Level 3.

Then SASS outputs a file with a BOM, which ends up in the middle of my concatenated files and causes other headaches.

I've specifically tried it and Sass 3.4.1 does not produce a BOM for me (though it didn't convert \f000 into Unicode for some reason, i had to manually type  into the source Sass).

Anyway, isn't it your concatenation tool's responsibility to produce valid files? BOM aside, the @charset directive should only appear in the very beginning of the resulting file. Sass takes care of that for you, but if you postprocess Sass-generated CSS files (which are CSS3-valid) and your postprocessor fails to produce a valid file, there isn't much Sass can do, is it?

[dwightjack]

@lolmaus Compliance matters, but sometimes projects didn't comply :p

I've specifically tried it and Sass 3.4.1 does not produce a BOM for me (though it didn't convert \f000 into Unicode for some reason, i had to manually type  into the source Sass).

I've experienced the conversion problem just with .sass extension and sass syntax. switching to .scss works as expected

[lolmaus]

@dwightjack, tried with .sass, still no BOM.

[dwightjack]

@lolmaus yep the BOM issue doesn't come up by changing extension, what's changing is that with .scss \f000 is preserved, while with .sass it's converted in 

[quantizor]

@lolmaus it's right in the documentation. If you output in compressed style and any utf-8 chars are detected, the file is outputted as UTF-8 with a BOM.

[quantizor]

I'm trying to force ASCII in every way I can think of, but 3.4's new behavior to convert the escaped characters into their real entities is defeating that effort.

[quantizor]

I'm using the scss CLI command to compile instead of sass, does that matter?

[nex3]

This is the expected behavior. Sass parses strings according to the CSS spec, and the spec says to interpret Unicode escapes as Unicode characters. The only reason the escapes might be preserved is the time-saving optimization wherein certain property values aren't parsed if we can guarantee they don't contain any dynamic code.

What is the actual practical problem with producing UTF-8 output? Is it exclusively other tools that don't handle @charset declarations/BOMs correctly?

[quantizor]

Well I guess I will never upgrade to 3.4 then. This is a big issue and SASS
shouldn't be fooling around with the input values, especially if we
specifically put a @charset "ASCII" at the top.
On Aug 28, 2014 1:44 PM, "Natalie Weizenbaum" notifications@github.com
wrote:

This is the expected behavior. Sass parses strings according to the CSS
spec, and the spec says to interpret Unicode escapes as Unicode characters.
The only reason the escapes might be preserved is the time-saving
optimization wherein certain property values aren't parsed if we can
guarantee they don't contain any dynamic code.

What is the actual practical problem with producing UTF-8 output? Is it
exclusively other tools that don't handle @charset declarations/BOMs
correctly?

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

[nex3]

SASS shouldn't be fooling around with the input values

This is literally Sass's entire job.

especially if we specifically put a @charset "ASCII" at the top.

The @charset declaration determines what the input character set is, not the output.

You still haven't answered my question: what practical problems does UTF-8 output cause?

[quantizor]

No, SASS's job is to rework selector trees, provide utility functions,
variables, etc. With the exception of changing color values to shortened
versions for compressed output, it historically has not tampered with the
values assigned to a property unless you specifically use a function of
some kind.

The issue is not UTF-8, but the fact that 3.4 outputs these files with a
byte order mark in compressed mode. This creates complications when
concatenating files together, because now all of a sudden there is a BOM in
the middle of the file and the browser CSS parser freaks out and drops the
next rule as invalid/malformed.

Could I set up another job to strip out BOM's? I guess, but SASS shouldn't
be including that character or doing this implicit conversion in the first
place.

[nex3]

No, SASS's job is to rework selector trees, provide utility functions, variables, etc. With the exception of changing color values to shortened versions for compressed output, it historically has not tampered with the values assigned to a property unless you specifically use a function of some kind.

Sass has parsed and reformatted property values for a long time. The guarantee it offers is that plain CSS input will produce semantically identical CSS output; Unicode characters are semantically identical to their escape codes, so this guarantee is being upheld.

The issue is not UTF-8, but the fact that 3.4 outputs these files with a byte order mark in compressed mode. This creates complications when concatenating files together, because now all of a sudden there is a BOM in the middle of the file and the browser CSS parser freaks out and drops the next rule as invalid/malformed.

So it is an issue with the tooling. I suggest you use a concatenation tool (such as Sass itself) that knows how to parse CSS files according to the spec.

[quantizor]

If I intended to put a unicode character in my stylesheet, I would have pasted in the actual character. The escaped sequence is in there for a reason and before 3.4, SASS didn't screw with that.

This is very upsetting in general. I'm kind of in disbelief that you would introduce such a change without documenting it more visibly.