Page Comparison

...

The jsass compiler will be used unless the code finds out that it is not available, in which case it will fall back to the vaadin compiler. This of course might make your files not compile.

Some Sass/SCSS pitfalls

I had some fun getting up to speed with sass. Here are some things important to know.

What the fsck are partials?

Existing Sass compilers will "watch" a directory of files, and will compile all files that end in ".sass" or ".scss" to the equivalent .css file as soon as a file changes or appears.

This is nice, except when files are only meant to be @import ed: those files should not be compiled to .css as they are meant to be part of another file. To prevent that you name the file with a starting underscore: this tells those other compilers that the file is not to be translated at all.

For DomUI this has no real meaning as it only reads the sass files that are requested and translates those on the fly. But we keep the convention because it allows you to also statically translate the sass files used in DomUI and just use the resulting css.

So: partials have no meaning at all in the compilation process: they are just files to be imported.

What does @import do

Import is confusing: it is actually what other languages call include: the source mentioned in the import is "copied" in the file doing the import at the location OF the import. So the following two files:

_file1.scss:

position: absolute;

file2.scss:

@import "file1";
@import "file1";
@import "file1";

will result in

position: absolute;
position: absolute;
position: absolute;

At the same time tools like IntelliJ complain when you use variables, mixins or functions that are defined in some other file: it tells you that the variable is guessed from files and that en import is needed.

To fix this you should do the following:

• Move all non-code producing things, like variables, functions, mixins and whatnot to separate fragments
• @import those fragments every time they are needed in some other fragment.