Use sassc directly

Most people who edit CSS in frameworks such as Rails and Sinatra write in the Sass language. I don't really care about it because the framework does it all, but in most cases you'll be taken care of by a gem called sassc [^ sassc] ..

[^ sassc]: Previously, a gem called sass was used, but it has been replaced by a fast sassc that implements the process in C.

This article is about dealing directly with sassc.

There are two types of Sass language syntax, the "Sass syntax" that existed from the beginning and the "SCSS syntax" that was added later. In this article, an example is shown using the Sass syntax [^ notation]. The SCSS syntax is essentially the same.

[^ notation]: I think the only advantage of SCSS syntax over Sass syntax is that it is "upward compatible with CSS", but why is SCSS overwhelmingly used?

Try using

require

In Gemfile

gem "sassc"

With a script

require "bundler"
Bundler.require

You can use it if you do.

Also, in the environment where sassc is installed, use a script

requrie "sassc"

You can use it if you do. In this article, the latter method is used.

Convert

Just give the source Sass source, create a SassC :: Engine object, and call the render method.

Write as follows.

require "sassc"

source = <<SASS
body
  margin: 0
SASS

p SassC::Engine.new(source, syntax: :sass, style: :compact).render
# => "body { margin: 0; }\n"

option

Important options for SassC :: Engine.new include:

:syntax

Give which syntax as a symbol.

For Sass syntax, use syntax:: sass, and for SCSS syntax, use syntax:: scss.

:style

Select the output format from : nested,: compact, : compressed,: expanded.

The smallest is : compressed.

The most common (?) Form of CSS is : expanded.

Handling of non-ASCII characters

I haven't checked the specifications, but it seems that the format of the conversion result is slightly different depending on whether it contains non-ASCII characters.

In fact, this is the motivation for writing an article. Of particular note is the compressed style, so compare this to expanded.

First, let's look at an example of ASCII characters only.

Sass

Sass

a
  font-family: "hoge"

Suppose. The output of expanded and compressed is as follows.

expanded style

a {
  font-family: "hoge";
}

compressed style

a{font-family:"hoge"}

There is nothing special about it.

Next, the following case where Sass contains non-ASCII characters.

Sass

a
  font-family: "Hoge"

If you output this as expanded, it will look like this:

expanded style

@charset "UTF-8";
a {
  font-family: "Hoge";
}

Hmm, with @charset" UTF-8 ";. I see, this makes sense.

So what about compressed?

compressed style

a{font-family:"Hoge"}

Oh? There is no @ charset. Is this okay?

To solve a mystery

In fact, in the previous experiment, CSS output in the compressed style when it contains non-ASCII characters seems to start with ʻa`, but that's not the case. There is a BOM (Byte Order Mark) at the beginning.

To confirm that

a
  font-family: "Hoge"

Let's display the first 5 character code points of the result of converting to CSS with compressed:

require "sassc"

source = <<SASS
a
  font-family: "Hoge"
SASS

css_text = SassC::Engine.new(source, syntax: :sass, style: :compressed).render

puts css_text.codepoints.take(5).map{ |c| "U+%04X" % c }.join(" ")
# => U+FEFF U+0061 U+007B U+0066 U+006F

After all, the first letter was U + FEFF, that is, BOM.

When I tried all four styles, only compressed had a BOM. In addition, BOM was not added for ASCII characters only.

I haven't investigated it well, but it seems that the above behavior is not a characteristic of the library called sassc, but a specification of the Sass language. Therefore, I think that the same result will be obtained even if it is done with other Sass processing systems such as Dart Sass (I have not confirmed it).

By the way, U + FEFF is invisible [^ invisible], so it is hard to notice that it is included. This sometimes causes a big problem, which I mentioned in another article below.

Watch out for the BOM that Sass spits out! --Qiita

[^ invisible]: It's a zero-width space, so it's natural that you can't see it. However, some display may be displayed depending on the viewing environment (text editor, code editor, terminal, etc.).