N cool things you may not have known about SCSS

Things you probably knew already...

...but are always worth mentioning, because they're incredibly cool compared to vanilla CSS:

Prefixing parent selector references

This is the familiar way:

a {
    &:hover {
        color: red;
    }
}

/* compiled CSS */
a:hover {
  color: red;
}

But & can be used with a prefix just as well:

p {
    body.no-touch & {
        display: none;
    }
}

/* compiled CSS */
body.no-touch p {
  display: none;
}

This can be very useful when you have a deep nesting of rules already in place, and you want to effect a change to the styling of an element based on a selector match much closer to the DOM root. Client capability flags such as the Modernizr no-touch class are often applied this way to the <body> element.

Variable interpolation in selectors

Variables can be expanded in selectors, too:

$alertClass: "error";

p.message-#{$alertClass} {
    color: red;
}

/* compiled CSS */
p.message-error {
  color: red;
}

...or almost anywhere else for that matter, like in media queries or CSS comments:

$breakpoint: 768px;

@media (max-width: #{$breakpoint}) {
    /* This block only applies to viewports <= #{$breakpoint} wide... */
}

/* compiled CSS */
@media (max-width: 768px) {
  /* This block only applies to viewports <= 768px wide... */
}

The media query example is particularly useful if the $breakpoint variable is defined in a _settings.scss, so the breakpoints of the entire application are configurable from one file.

Variable defaults

If your SCSS module can be configured using globals (which tends to be the SCSS way), you can declare them with a default value:

// _my-module.scss:
$message-color: blue !default;

p.message {
    color: $message-color;
}

/* compiled CSS */
p.message {
  color: blue;
}

But you can then optionally override the module defaults before its inclusion:

$message-color: black;
@import 'my-module';

/* compiled CSS */
p.message {
  color: black;
}

That is, an assignment with a !default will only take effect if such a variable didn't have a value before (in contrast to the standard assignment, which will always overwrite a possible previous value).

This is how many SCSS modules (including most that ship with Compass) are configured.

Control directives

SCSS sports the standard set of flow control directives, such as if:

$debug: false; // TODO: move to _settings.scss

article {
    color: black;

    @if ($debug) { // visualizing layout internals
        border: 1px dotted red;
    }
}

/* compiled CSS */
article {
  color: black;
}

Having such compile-time flags in your project's styling can help debug complex layout issues visually, faster than just inspecting the page an element at a time.

There's also @for, @each and @while. They're good for a number of use cases that would otherwise need lots of repetitive (S)CSS, like:

@each $name in 'save' 'cancel' 'help' {
    .icon-#{$name} {
        background-image: url('/images/#{$name}.png');
    }
}

/* compiled CSS */
.icon-save {
  background-image: url("/images/save.png");
}
.icon-cancel {
  background-image: url("/images/cancel.png");
}
.icon-help {
  background-image: url("/images/help.png");
}

...and much more. Keep in mind, though, that if you need them in your daily styling work you're probably overdoing it. Instead, they usually warrant the added complexity when building configurable SCSS modules and other such reusable components.

The interested reader can check out the full documentation on control directives.

The list data type

As we saw in the previous example, @each can iterate over a list. Lists are in fact a fundamental part of the SCSS language, but a quick demo of their application might be configuring some generated styling:

$buttonConfig: 'save' 50px, 'cancel' 50px, 'help' 100px; // TODO: move to _settings.scss

@each $tuple in $buttonConfig {
    .button-#{nth($tuple, 1)} {
        width: nth($tuple, 2);
    }
}

/* compiled CSS */
.button-save {
  width: 50px;
}
.button-cancel {
  width: 50px;
}
.button-help {
  width: 100px;
}

This demonstrates two features of the list data type, namely the nth() list accessor function, and more interestingly list nestability: in JavaScript notation, the above would be equivalent to:

var buttonConfig = [[ 'save', 50 ], [ 'cancel', 50 ], [ 'help', 100 ]];

That is, lists can be separated by both spaces and commas, and alternation between the two notations produces nested lists.

Defining custom functions

Mixins are a well-known part of the language, but SCSS also allows you to define custom functions. Contrary to what one might expect, this can also be done in pure SCSS, instead of extending SCSS in Ruby:

@function make-greener($value) {
    @return $value + rgb(0,50,0); // arithmetic with colors is _b
}
p {
    background: make-greener(gray);
}

/* compiled CSS */
p {
  background: #80b280;
}

The above color is a gray with a slight green tint.

Functions are most useful in avoiding some repeated computation in an expression. It also implicitly documents that computation by giving it a name: the above example, while contrived, is still more understandable than just having arbitrary color arithmetic in the style block. SCSS ships with a ton of useful built-in functions, and Compass adds even more, so do first check whether there's a built-in equivalent before implementing your own helper.

Argument defaults

Arguments and functions support default values for arguments; the last zero-to-N arguments can be made optional by providing them with a default value:

@mixin foobar($a, $b, $padding: 20px) {
    padding: $padding;
    // ...and something with $a and $b
}

p {
    @include foobar(123, "abc"); // the default padding's fine
}

p.important {
    @include foobar(123, "abc", 50px); // override the default
}

Keyword arguments

If your mixin (or function) takes a lot of arguments, there's a similar call-time syntax for selecting only specific arguments to override:

@mixin foobar($topPadding: 10px, $rightPadding: 20px, $bottomPadding: 10px, $leftPadding: 20px, $evenMorePadding: 10px) {
    // do something with all these arguments...
}

p {
    @include foobar($bottomPadding: 50px); // specify only the argument you want to override
}

However, in cases where a lot of the arguments are just for overriding specific CSS properties (such as top-padding, bottom-padding and so on), the "content block overrides -pattern" is likely a better fit (see below).

Variable arguments for functions/mixins

Var-args work much the same way as in other languages that support the feature; any extra arguments to a function/mixin call are wrapped into a list and assigned to the argument having a ... suffix:

@mixin config-icon-colors($prefix, $colors...) {
    @each $i in $colors {
        .#{$prefix}#{nth($i, 1)} {
            color: nth($i, 2);
        }
    }
}
@include config-icon-colors('icon-',
    'save'   green,
    'cancel' gray,
    'delete' red
);

/* compiled CSS */
.icon-save {
  color: green;
}
.icon-cancel {
  color: gray;
}
.icon-delete {
  color: red;
}

The above helper could be used to set up colors for your font icons, Font Awesome for example, without having to repeat yourself. The helper works by passing in a variable number of arguments (after the first, required one). Each of those arguments is expected to be a tuple of two items (again in JavaScript notation, for example [ "save", "green" ]).

In fact, the ... syntax also works during call-time, where it expands a list into separate arguments, to be fed into the target mixin:

@mixin foobar($a, $b, $c) {
    // receives args $a = 5px, $b = red, and so on
}

$myArgs: 5px red "bla bla";
// at this point, you could also programmatically add/remove arguments

@include foobar($myArgs...);

Personally, I have yet to find a use case for this, but the documentation has a nice use case for passing current arguments forward to another mixin.

Content block arguments for mixins

Since version 3.2.0, SCSS has had an implicit mixin argument accessible through the @content directive. It allows passing an entire SCSS content block as an argument to the mixin:

@mixin only-for-mobile {
    @media (max-width: 768px) {
        @content;
    }
}

@include only-for-mobile() /* note: @content begins here */ {
    p {
        font-size: 150%;
    }
} /* @content ends */

/* compiled CSS */
@media (max-width: 768px) {
  p {
    font-size: 150%;
  }
}

This is a very powerful language feature. You can mix standard and content block arguments, too:

@mixin only-for-mobile($breakpoint) {
    @media (max-width: #{$breakpoint}) {
        @content;
    }
}

@include only-for-mobile(480px) {
    p {
        font-size: 150%;
    }
}

Content block overrides -pattern

Consider a mixin that generates a selector and a corresponding style block, allowing the caller to customize the styling if needed:

@mixin message($class, $color: yellow, $margin: 20px, $padding: 10px) {
    .message-#{$class} {
        border: 1px dotted $color;
        color: $color;
        margin: $margin;
        padding: $padding;
    }
}

Calling this mixin using keyword arguments (see above) is quite convenient, because if the defaults are fine, no extra arguments need be provided. If they're not, you only need to specify the arguments you want to override:

@include message("subtle", $margin: 5px);

But this requires you to list all overridable properties in the mixin signature. However, content block arguments allow arbitrary overrides without the argument jungle:

@mixin message($class) {
    .message-#{$class} {
        border: 1px dotted yellow;
        color: yellow;
        margin: 20px;
        padding: 10px;
        @content;
    }
}

@include message("subtle") {
    margin: 5px;
}

/* compiled CSS */
.message-subtle {
  border: 1px dotted yellow;
  color: yellow;
  margin: 20px;
  padding: 10px;
  margin: 5px;
}

Here, we allow the good-ole CSS cascade to effect the property override (the latter margin overrides the former one). Also, we're not limited to overriding the properties the author of the mixin thought of. In fact, this allows passing in nested blocks as well:

@include message("actionable") {
    button {
        float: right;
    }
}

/* compiled CSS */
.message-actionable {
  border: 1px dotted yellow;
  color: yellow;
  margin: 20px;
  padding: 10px;
}
.message-actionable button {
  float: right;
}

This pattern can be useful in any library code that outputs nontrivial styling with generated selectors; in simple cases (where no selectors are emitted within the mixin) it's of course rather unnecessary, as any overrides can be made directly after the mixin call.

Media query bubbling

@media blocks

p {
    @media (max-width: 768px) {
        // Use larger text for smaller screens:
        font-size: 150%;
    }
}

Compiles into:

/* compiled CSS */
@media (max-width: 768px) {
  p {
    font-size: 150%;
  }
}

Media query nesting

p {
    @media (max-width: 768px) {

        // Use larger text for smaller screens:
        font-size: 150%;

        @media (orientation: landscape) {

            // Condense text a bit because of small vertical space:
            line-height: 75%;
        }
    }
}