Skip to content

Instantly share code, notes, and snippets.

@craftystudio
Forked from jareware/SCSS.md
Created February 11, 2019 07:52

Revisions

  1. @jareware jareware revised this gist Oct 30, 2013. 1 changed file with 2 additions and 0 deletions.
    2 changes: 2 additions & 0 deletions SCSS.md
    Original file line number Diff line number Diff line change
    @@ -1,3 +1,5 @@
    [⇐ back to the gist-blog at jrw.fi](http://jrw.fi/)

    # Advanced SCSS

    Or, **16 cool things you may not have known your stylesheets could do.** I'd rather have kept it to a nice round number like 10, but they just kept coming. Sorry.
  2. @jareware jareware revised this gist Aug 4, 2013. 1 changed file with 13 additions and 3 deletions.
    16 changes: 13 additions & 3 deletions SCSS.md
    Original file line number Diff line number Diff line change
    @@ -2,16 +2,18 @@

    Or, **16 cool things you may not have known your stylesheets could do.** I'd rather have kept it to a nice round number like 10, but they just kept coming. Sorry.

    I've been using [SCSS/SASS](http://sass-lang.com/) for most of my styling work since 2009, and I'm a huge fan of [Compass](http://compass-style.org/) (by the great [@chriseppstein](https://twitter.com/chriseppstein)). It really helped many of us through the darkest cross-browser crap. Even though browsers are increasingly playing nice with CSS, another problem has become very topical: managing the complexity in stylesheets as our in-browser apps get larger and larger. SCSS is an indispensable tool for dealing with this.

    This isn't an [introduction to the language](http://sass-lang.com/tutorial.html) by a long shot; many things probably won't make sense unless you have some SCSS under your belt already. That said, if you're not yet comfy with the basics, check out the awesome CSS extensions you've always wished you had:

    * [Nested selectors](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#css_extensions)
    * [Variables](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#variables_)
    * [Mixins](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#mixins)
    * and loads more

    Also, if you have any questions, comments or corrections, leave a comment below, or fork this gist and let me know!
    The tips are vaguely ordered from basic to more advanced. If you're immediately bored, feel free to skip ahead to the deep end of the pool. Also, if you have any questions, comments or corrections, leave a comment below, or fork this gist and let me know!

    So without further ado, on to the *cool things*. The tips are vaguely ordered from basic to more advanced. If you're immediately bored, feel free to skip ahead to the deep end of the pool.
    So without further ado, on to the *cool things*.

    ## 1. Prefixing parent selector references

    @@ -644,4 +646,12 @@ Potential downsides with this approach should be kept in mind:

    ## And that's it
    Closing words..?
    Hope you picked up something useful!
    There may be more at [my site](http://jrw.fi/) or [@jareware](https://twitter.com/jareware), depending on when you look. :)
    Cheers,
    \- Jarno
    ![GA](https://ssl.google-analytics.com/__utm.gif?utmwv=5.4.3&utmn=47004&utmhn=gist.github.com&utmdt=Advanced%20SCSS%2C%20or%2C%2016%20cool%20things%20you%20may%20not%20have%20known%20your%20stylesheets%20could%20do&utmr=-&utmp=%2Fjareware%2F4738651&utmac=UA-42176157-3&utmcc=__utma%3D1.1828258468.1374783534.1374783534.1374783534.1%3B%2B__utmz%3D1.1374783534.1.1.utmcsr%3D(direct\)%7Cutmccn%3D(direct\)%7Cutmcmd%3D(none\)%3B)
  3. @jareware jareware revised this gist Jul 31, 2013. 1 changed file with 45 additions and 29 deletions.
    74 changes: 45 additions & 29 deletions SCSS.md
    Original file line number Diff line number Diff line change
    @@ -240,7 +240,7 @@ p {
    ```
    Without being able to name arguments call-time, you'd have to specify `$topPadding` and `$rightPadding` first. Now, you can instead override *only* the argument you want, leaving the rest to their default values.

    Note, however, that 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).
    Note, however, that 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).

    ## 9. Variable arguments for functions/mixins

    @@ -290,7 +290,7 @@ $myArgs: 5px red "bla bla";

    Personally, I have yet to find a use case for this, but [the documentation](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#variable_arguments) has a nice use case for passing current arguments forward to another mixin.

    ## Content block arguments for mixins
    ## 10. Content block arguments for mixins

    Since [version 3.2.0](http://sass-lang.com/docs/yardoc/file.SASS_CHANGELOG.html#320_10_august_2012), 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:

    @@ -316,7 +316,7 @@ Since [version 3.2.0](http://sass-lang.com/docs/yardoc/file.SASS_CHANGELOG.html#
    }
    ```

    This is a very powerful language feature. You can mix standard and content block arguments, too:
    This is a *very* powerful language feature for framework authors, as it allows you to pass arbitrary blocks of styling around, which you can choose to wrap in specific selectors, repeat in loops, make conditional with `@if`, etc. You can mix standard and content block arguments, too:

    ```scss
    @mixin only-for-mobile($breakpoint) {
    @@ -332,9 +332,9 @@ This is a very powerful language feature. You can mix standard and content bloc
    }
    ```

    ## Content block overrides -pattern
    ## 11. 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:
    Consider a mixin that generates a selector and some styles for it, allowing the caller to customize the styling if needed:
    ```scss
    @mixin message($class, $color: yellow, $margin: 20px, $padding: 10px) {
    .message-#{$class} {
    @@ -378,7 +378,7 @@ But this requires you to list *all overridable properties* in the mixin signatur
    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:
    ```scss
    @include message("actionable") {
    button {
    button { // actionable messages may contain buttons for taking action!
    float: right;
    }
    }
    @@ -395,33 +395,47 @@ Here, we allow the good-ole CSS cascade to effect the property override (the lat
    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.
    This pattern can be useful in any library code that outputs nontrivial styling with generated selectors, since it allows the user a customization point beyond what the library author foresaw. Note, though, that in simple cases (where no selectors are emitted within the mixin) it's rather unnecessary, as any overrides can be made just using the standard CSS cascade.
    ## Media query bubbling
    ## 12. Media query bubbling
    `@media` blocks do not need to be declared at the root level of the stylesheet:
    ```scss
    p {
    @media (max-width: 768px) {
    font-size: 150%; // use larger text for smaller screens
    body {
    article {
    p {
    font-size: 100%;
    color: black;
    padding: 10px;
    @media (max-width: 768px) {
    font-size: 150%; // use larger text for smaller screens
    }
    }
    }
    }
    ```
    ```css
    /* compiled CSS */
    body article p {
    font-size: 100%;
    color: black;
    padding: 10px;
    }
    @media (max-width: 768px) {
    p {
    body article p {
    font-size: 150%;
    }
    }
    ```
    Notice how the compiler "bubbles up" the `@media` block to the root level (since regular CSS doesn't support selector nesting), and then outputs within all styling and the corresponding selectors that were encountered within the `@media` block in the SCSS source.
    Notice how the compiler "bubbles up" the `@media` block to the root level (since regular CSS doesn't support selector nesting), and within it, outputs all styling that was encountered within the `@media` block in the SCSS source.

    This is very useful as it allows you to make media-specific tweaks almost anywhere in your styling, right where they're relevant, instead of collecting all those tweaks to the end of the stylesheet, and hoping that their selectors will stay in sync with the ones they're overriding (they won't).
    ## Media query nesting
    ## 13. Media query nesting
    The aforementioned bubbling mechanism also takes nesting into account, and combines all applicable queries with the `and` media query operator:
    The aforementioned bubbling mechanism also takes nesting into account, and combines all applicable queries with the `and` operator:
    ```scss
    p {
    @media (max-width: 768px) {
    @@ -446,7 +460,7 @@ p {
    }
    ```
    ## Extending selectors
    ## 14. Extending selectors
    SCSS allows [extending selectors](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#extend), by copying and combining selectors in the CSS output. Interestingly, while the mechanism is (obviously) very different, the semantics of `@extend` are quite analogous to traditional object-oriented programming languages (such as Java & whatnot):
    ```scss
    @@ -467,9 +481,9 @@ SCSS allows [extending selectors](http://sass-lang.com/docs/yardoc/file.SASS_REF
    color: white;
    }
    ```
    That is, `.cat` has all the properties of its "parent class" `.animal`, plus any specific ones it adds or overrides. Whereas in normal CSS you would have to reference both the extending class and the parent class (e.g. `<div class="animal cat">`), now you can only name the exact class you want (`<div class="cat">`). What it does (or doesn't) inherit from depends on the definition of `.cat`.
    That is, `.cat` has all the properties of its "parent class" `.animal`, plus any specific ones it adds or overrides. Whereas in normal CSS you would have to reference both the extending class and the parent class (e.g. `<div class="animal cat">`), now you can just name the exact class you want (`<div class="cat">`). What it does (or doesn't) inherit from depends on the definition of `.cat`, and can later change without touching the markup.

    Classical inheritance, right? Overriding properties in the "child class" works due to the style cascade in the browser: styling for the same selector that comes later in the file always wins over the styling that came before it. Perhaps a bit unintuitively, this actually works out fine even if the combined selectors have differing [specificity](http://www.w3.org/TR/css3-selectors/#specificity) (think `.class` overriding an `#id`). Extending selectors may often be preferable to using mixins to achieve the same effect:
    Classical inheritance, right? Overriding properties in the "child class" works due to the style cascade in the browser: styling for the same selector that comes later in the file always wins over the styling that came before it. Perhaps a bit unintuitively, this actually works out fine even if the combined selectors have differing [specificity](http://www.w3.org/TR/css3-selectors/#specificity) (think `.class` extending an `#id`). Extending selectors may often be preferable to using mixins to achieve the same effect:
    ```scss
    @mixin animal {
    background: gray;
    @@ -509,7 +523,7 @@ Classical inheritance, right? Overriding properties in the "child class" works
    color: black;
    }
    ```
    Notice how only the last property (`color`) is different. As we define more types of animals, the amount of repeated style properties keeps growing. This is in contrast to how selector extension would solve the same problem:
    Notice how only the last property (`color`) is different, the rest is the same. As we define more types of animals, the amount of repeated style properties in the CSS output keeps growing. This is in contrast to how selector extension would solve the same problem:
    ```scss
    .animal {
    background: gray;
    @@ -545,19 +559,21 @@ Notice how only the last property (`color`) is different. As we define more typ
    color: black;
    }
    ```
    Finally, selector extension allows for integrations into 3rd party CSS libraries, that need not be specifically designed for extension, or even be written in SCSS. [Twitter Bootstrap](http://twitter.github.io/bootstrap/), for example, includes nice styling for buttons, but doesn't apply it to `<button>` elements by default. In our quest to reduce unnecessary CSS classes, we can fix this simply with:
    Finally, selector extension allows for integrations into 3rd party CSS libraries, that need not be specifically designed for extension, or even be written in SCSS. [Twitter Bootstrap](http://twitter.github.io/bootstrap/), for example, includes nice styling for buttons with `.btn`, but doesn't apply it to `<button>` elements by default. In our quest to reduce unnecessary CSS classes, we can fix this simply with:
    ```scss
    @import "bootstrap.scss"; // just a renamed .css file, so that @import works

    button {
    @extend .btn;
    }
    ```
    This will add the `button` selector into the Bootstrap source wherever `.btn` is referenced.
    This will add the `button` selector into the Bootstrap source wherever `.btn` is defined.

    The extension mechanism is surprisingly clever even with [more complex selectors](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#extending_complex_selectors), and allows [chaining extends](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#chaining_extends) (think `.cat` extends `.feline` extends `.animal`), but with great power comes great responsibility: overly [neat tricks](http://thedailywtf.com/Articles/Classic-WTF-Now-Thats-A-Neat-Trick.aspx) with `@extend` may be hard to reason about when debugging styles. Use responsibly.

    ## Placeholder selectors
    ## 15. Placeholder selectors

    Because in the above example(s) the `.animal` base class isn't used anywhere directly (only through its child classes), we might just as well get rid of it in the CSS output. SCSS allows this with [placeholder selectors](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#placeholders) - whereas `.foo` signifies a class, and `#foo` an ID, `%foo` is considered a placeholder, and gets special treatment by the parser: its styles are never output on their own, only through extension.
    Because in the above example(s) the `.animal` base class isn't used anywhere directly (only through its child classes), we might just as well get rid of it in the CSS output. SCSS allows this with [placeholder selectors](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#placeholders). Whereas `.foo` signifies a class, and `#foo` an ID, `%foo` is considered a placeholder, and gets special treatment by the compiler: its styles are never output on their own, only through extension.
    ```scss
    %animal {
    background: gray;
    @@ -584,11 +600,11 @@ Because in the above example(s) the `.animal` base class isn't used anywhere dir
    color: black;
    }
    ```
    Because `%animal` was just a placeholder selector, it's disappeared from the output. As an added benefit, if you never define a selector that extends `%animal`, its styles (`background: gray;` and so on) are completely omitted. This can be very useful in SCSS framework authoring, as you can offer any number of base classes for opt-in extension, but only the ones actually *used* are output into the resulting CSS.
    Because `%animal` was just a placeholder selector, it's disappeared from the output. More importantly, if you never define a selector that extends `%animal`, its styles (`background: gray;` and so on) are completely omitted from the output. This can be very useful for SCSS framework authors, as you can offer any number of base classes for opt-in extension, but only the ones actually *used* are output into the resulting CSS.

    Placeholder selectors can actually do even more than this, namely expanding the `%placeholder` part into a more complex selector during `@extend`, but personally I've never had to use this feature. The interested reader can check out the [docs on the subject](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#placeholders).
    ## Selector multiple inheritance
    ## 16. Selector multiple inheritance
    A selector can actually inherit from *several* other selectors - that is, SCSS supports multiple inheritance. For each `@extend`, the current selector is appended to the selector being extended. When combined with placeholder selectors, this allows powerful abstractions for styling framework authors. This is perhaps best explained through an example:
    ```scss
    @@ -616,14 +632,14 @@ A selector can actually inherit from *several* other selectors - that is, SCSS s
    ```
    This way of constructing styling has a few notable benefits:
    * **Self-documentation:** Instead of writing out loads of anonymoud style properties, the author instead describes the "traits" of the UI component he is designing.
    * **Naming isolation:** The application can use its own naming conventions and semantics in the HTML, while the framework naming conventions never make their way into the compiled CSS. In the above example, the framework adopts a common prefix `%mfw` (for "my framework", or whatever) to avoid naming collisions with other SCSS libraries.
    * **Self-documentation:** Instead of writing out loads of anonymous style properties, the author instead lists the "traits" of the UI component he is designing. The names of the traits can be as long & descriptive as needed (they won't appear in the CSS output).
    * **Naming isolation:** The application can use whichever naming conventions and semantics in the HTML, while the framework naming conventions stay internal to the SCSS source. In the above example, the framework adopts a common prefix `%mfw` (for "my framework", or whatever) to avoid naming collisions with other SCSS libraries.
    * **Reduced repetition:** The `#join-button` could use the `border-radius()` and `box-shadow()` helpers directly to achieve the same stylistic effect. But for each additional component that does so, the `box-shadow()` helper would output the exact same lines of CSS, with all the vendor prefixes and whatnot. Extending `%mfw-slightly-shadowed`, however, would simply append the selector to the list of other selectors that should receive shadowing.
    * **Opt-in:** If a specific "trait" is never used to describe some UI component, its styles are never output. That is, if you just use 1% of the features of a bloated style framework, your CSS payload will only contain that 1%. Contrast this to the de-facto way of just including an entire Bootstrap or jQuery, because the site uses 1 or 2 features from each.
    * **Opt-in:** If a specific "trait" is never used to describe a UI component, its styles are never output. That is, if you just use 1% of the features of a bloated style framework, your CSS payload will only contain that 1%. Contrast this to the de-facto way of just including an entire Bootstrap or jQuery, because the site uses 1 or 2 features from each.

    Potential downsides with this approach should be kept in mind:

    * **Debuggability:** Without properly configured [source maps for SCSS](http://bricss.net/post/33788072565/using-sass-source-maps-in-webkit-inspector), it may be harder to figure out how some styling ended up affecting a specific element (keep in mind the above point about *self-documentation* no longer applies in the compiled CSS).
    * **Debuggability:** Without properly configured [source maps for SCSS](http://bricss.net/post/33788072565/using-sass-source-maps-in-webkit-inspector), it may be harder to figure out how some styling ended up affecting a specific element (keeping in mind the above point about *self-documentation* no longer applies in the compiled CSS).
    * **Arguments:** This technique won't replace mixins when computation is required based on some arguments. While there can be several versions of each "trait" (think `%mfw-slightly-shadowed` vs `%mfw-heavily-shadowed`), they'll always be completely static in content.

    ## And that's it
  4. @jareware jareware revised this gist Jul 28, 2013. 1 changed file with 25 additions and 23 deletions.
    48 changes: 25 additions & 23 deletions SCSS.md
    Original file line number Diff line number Diff line change
    @@ -33,7 +33,7 @@ But `&` can be used with a prefix just as well:
    ```scss
    p {
    body.no-touch & {
    display: none;
    display: none; // hide the message if not on a touch device
    }
    }
    ```
    @@ -43,9 +43,9 @@ 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](http://modernizr.com/docs/) `no-touch` class are often applied this way to the `<body>` element.
    This can be very useful when you have a deep nesting of rules, 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](http://modernizr.com/docs/) `no-touch` class are often applied this way to the `<body>` element. This way you don't have to back out of your nesting just to be able to change your `<p>` styling based on a class on the `<body>`.

    ## Variable interpolation in selectors
    ## 2. Variable expansion in selectors

    Variables can be expanded in selectors, too:
    ```scss
    @@ -76,9 +76,9 @@ $breakpoint: 768px;
    }
    ```

    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.
    The media query example is particularly useful if the `$breakpoint` variable is defined in a settings partial somewhere (say, `_settings.scss`), so the breakpoints of the entire application are configurable from one file.

    ## Variable defaults
    ## 3. 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:
    ```scss
    @@ -110,7 +110,7 @@ That is, an assignment with a `!default` will only take effect if such a variabl

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

    ## Control directives
    ## 4. Control directives

    SCSS sports the standard set of flow control directives, such as `if`:
    ```scss
    @@ -152,13 +152,13 @@ There's also `@for`, `@each` and `@while`. They're good for a number of use cas
    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.
    ...and much more. Keep in mind, though, that if you need them in your daily styling work you're probably overdoing it a bit. Instead, the added complexity is usually justified when building configurable SCSS modules and such.
    The interested reader can check out the [full documentation on control directives](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#control_directives).
    ## The list data type
    ## 5. The list data type
    As we saw in the previous example, `@each` can iterate over a list. Lists are in fact a [fundamental part](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#lists) of the SCSS language, but a quick demo of their application might be configuring some generated styling:
    As we saw in the previous example, `@each` can iterate over a list. Lists are in fact a [fundamental part](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#lists) of the SCSS language, but a quick demonstration of their usefulness might be configuring some generated styling:
    ```scss
    $buttonConfig: 'save' 50px, 'cancel' 50px, 'help' 100px; // TODO: move to _settings.scss
    @@ -186,12 +186,12 @@ 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
    ## 6. Defining custom functions
    [Mixins](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#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](http://sass-lang.com/docs/yardoc/Sass/Script/Functions.html#adding_custom_functions):
    ```scss
    @function make-greener($value) {
    @return $value + rgb(0,50,0); // arithmetic with colors is _b
    @return $value + rgb(0,50,0); // arithmetic with colors is totally fine, btw
    }
    p {
    background: make-greener(gray);
    @@ -205,12 +205,11 @@ p {
    ```
    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](http://sass-lang.com/docs/yardoc/Sass/Script/Functions.html), and Compass [adds even more](http://compass-style.org/reference/compass/helpers/), so do first check whether there's a built-in equivalent before implementing your own helper.
    Custom 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](http://sass-lang.com/docs/yardoc/Sass/Script/Functions.html), and Compass [adds even more](http://compass-style.org/reference/compass/helpers/), so do first check whether there's a built-in equivalent before implementing your own.

    ## 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:
    ## 7. Argument defaults

    Mixins and functions support default values for arguments; the *last* zero-to-N arguments can be made optional by providing them with a default value:
    ```scss
    @mixin foobar($a, $b, $padding: 20px) {
    padding: $padding;
    @@ -226,23 +225,24 @@ p.important {
    }
    ```

    ## 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:
    ## 8. Keyword arguments

    If your mixin (or function) takes *a lot* of arguments, there's a similar call-time syntax for selecting specific arguments to override:
    ```scss
    @mixin foobar($topPadding: 10px, $rightPadding: 20px, $bottomPadding: 10px, $leftPadding: 20px, $evenMorePadding: 10px) {
    @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
    @include foobar($bottomPadding: 50px);
    }
    ```
    Without being able to name arguments call-time, you'd have to specify `$topPadding` and `$rightPadding` first. Now, you can instead override *only* the argument you want, leaving the rest to their default values.

    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).
    Note, however, that 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
    ## 9. Variable arguments for functions/mixins

    [Var-args](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#variable_arguments) 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:

    @@ -626,4 +626,6 @@ Potential downsides with this approach should be kept in mind:
    * **Debuggability:** Without properly configured [source maps for SCSS](http://bricss.net/post/33788072565/using-sass-source-maps-in-webkit-inspector), it may be harder to figure out how some styling ended up affecting a specific element (keep in mind the above point about *self-documentation* no longer applies in the compiled CSS).
    * **Arguments:** This technique won't replace mixins when computation is required based on some arguments. While there can be several versions of each "trait" (think `%mfw-slightly-shadowed` vs `%mfw-heavily-shadowed`), they'll always be completely static in content.
    ...and that's it!
    ## And that's it

    Closing words..?
  5. @jareware jareware revised this gist Jul 28, 2013. 1 changed file with 10 additions and 5 deletions.
    15 changes: 10 additions & 5 deletions SCSS.md
    Original file line number Diff line number Diff line change
    @@ -1,16 +1,21 @@
    # N cool things you may not have known about SCSS
    # Advanced SCSS

    ## Things you probably knew already...
    Or, **16 cool things you may not have known your stylesheets could do.** I'd rather have kept it to a nice round number like 10, but they just kept coming. Sorry.

    ...but are always worth mentioning, because they're incredibly cool compared to vanilla CSS:
    This isn't an [introduction to the language](http://sass-lang.com/tutorial.html) by a long shot; many things probably won't make sense unless you have some SCSS under your belt already. That said, if you're not yet comfy with the basics, check out the awesome CSS extensions you've always wished you had:

    * [Nested selectors](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#css_extensions)
    * [Variables](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#variables_)
    * [Mixins](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#mixins)
    * and loads more

    ## Prefixing parent selector references
    Also, if you have any questions, comments or corrections, leave a comment below, or fork this gist and let me know!

    This is the familiar way:
    So without further ado, on to the *cool things*. The tips are vaguely ordered from basic to more advanced. If you're immediately bored, feel free to skip ahead to the deep end of the pool.

    ## 1. Prefixing parent selector references

    This is the familiar way you're probably using `&`:
    ```scss
    a {
    &:hover {
  6. @jareware jareware revised this gist Jul 28, 2013. 1 changed file with 37 additions and 1 deletion.
    38 changes: 37 additions & 1 deletion SCSS.md
    Original file line number Diff line number Diff line change
    @@ -585,4 +585,40 @@ Placeholder selectors can actually do even more than this, namely expanding the
    ## Selector multiple inheritance
    TODO
    A selector can actually inherit from *several* other selectors - that is, SCSS supports multiple inheritance. For each `@extend`, the current selector is appended to the selector being extended. When combined with placeholder selectors, this allows powerful abstractions for styling framework authors. This is perhaps best explained through an example:
    ```scss
    // in the framework files:
    %mfw-standing-out {
    font-size: 150%;
    font-style: italic;
    padding: 25px;
    }
    %mfw-slightly-shadowed {
    @include box-shadow(black 2px 2px 10px); // from Compass
    }
    %mfw-rounded {
    @include border-radius(25px); // from Compass
    }
    // in the application files:
    #join-button {
    @extend %mfw-standing-out;
    @extend %mfw-slightly-shadowed;
    @extend %mfw-rounded;
    background: green;
    color: white;
    }
    ```
    This way of constructing styling has a few notable benefits:
    * **Self-documentation:** Instead of writing out loads of anonymoud style properties, the author instead describes the "traits" of the UI component he is designing.
    * **Naming isolation:** The application can use its own naming conventions and semantics in the HTML, while the framework naming conventions never make their way into the compiled CSS. In the above example, the framework adopts a common prefix `%mfw` (for "my framework", or whatever) to avoid naming collisions with other SCSS libraries.
    * **Reduced repetition:** The `#join-button` could use the `border-radius()` and `box-shadow()` helpers directly to achieve the same stylistic effect. But for each additional component that does so, the `box-shadow()` helper would output the exact same lines of CSS, with all the vendor prefixes and whatnot. Extending `%mfw-slightly-shadowed`, however, would simply append the selector to the list of other selectors that should receive shadowing.
    * **Opt-in:** If a specific "trait" is never used to describe some UI component, its styles are never output. That is, if you just use 1% of the features of a bloated style framework, your CSS payload will only contain that 1%. Contrast this to the de-facto way of just including an entire Bootstrap or jQuery, because the site uses 1 or 2 features from each.
    Potential downsides with this approach should be kept in mind:
    * **Debuggability:** Without properly configured [source maps for SCSS](http://bricss.net/post/33788072565/using-sass-source-maps-in-webkit-inspector), it may be harder to figure out how some styling ended up affecting a specific element (keep in mind the above point about *self-documentation* no longer applies in the compiled CSS).
    * **Arguments:** This technique won't replace mixins when computation is required based on some arguments. While there can be several versions of each "trait" (think `%mfw-slightly-shadowed` vs `%mfw-heavily-shadowed`), they'll always be completely static in content.
    ...and that's it!
  7. @jareware jareware revised this gist Jul 28, 2013. 1 changed file with 3 additions and 3 deletions.
    6 changes: 3 additions & 3 deletions SCSS.md
    Original file line number Diff line number Diff line change
    @@ -462,9 +462,9 @@ SCSS allows [extending selectors](http://sass-lang.com/docs/yardoc/file.SASS_REF
    color: white;
    }
    ```
    That is, `.cat` has all the properties of its "parent class" `.animal`, plus any specific ones it adds or overrides. Whereas in normal CSS you would have to reference both the extending class and the parent class (e.g. `<div class="animal cat"></div>`), now you can only name the exact class you want, regardless of what it inherits from (`<div class="cat"></div>`).
    That is, `.cat` has all the properties of its "parent class" `.animal`, plus any specific ones it adds or overrides. Whereas in normal CSS you would have to reference both the extending class and the parent class (e.g. `<div class="animal cat">`), now you can only name the exact class you want (`<div class="cat">`). What it does (or doesn't) inherit from depends on the definition of `.cat`.
    Classical inheritance, right? Overriding properties in the "child class" works due to the style cascade in the browser: styling that comes later in the file always wins over the styling that came before it (unless the combined selectors have differing [specificity](http://www.w3.org/TR/css3-selectors/#specificity), which is something to watch out for when extending selectors). Extending selectors may often be preferable to using mixins to achieve the same effect:
    Classical inheritance, right? Overriding properties in the "child class" works due to the style cascade in the browser: styling for the same selector that comes later in the file always wins over the styling that came before it. Perhaps a bit unintuitively, this actually works out fine even if the combined selectors have differing [specificity](http://www.w3.org/TR/css3-selectors/#specificity) (think `.class` overriding an `#id`). Extending selectors may often be preferable to using mixins to achieve the same effect:
    ```scss
    @mixin animal {
    background: gray;
    @@ -552,7 +552,7 @@ This will add the `button` selector into the Bootstrap source wherever `.btn` is

    ## Placeholder selectors

    Because in the above example(s) the `.animal` base class isn't really used anywhere directly, having such a superfluous class name in the CSS output may seem unnecessary. SCSS allows you to overcome this with [placeholder selectors](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#placeholders) - whereas `.foo` signifies a class, and `#foo` an ID, `%foo` is considered a placeholder, and gets special treatment by the parser: its styles are never output on their own, only through extension.
    Because in the above example(s) the `.animal` base class isn't used anywhere directly (only through its child classes), we might just as well get rid of it in the CSS output. SCSS allows this with [placeholder selectors](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#placeholders) - whereas `.foo` signifies a class, and `#foo` an ID, `%foo` is considered a placeholder, and gets special treatment by the parser: its styles are never output on their own, only through extension.
    ```scss
    %animal {
    background: gray;
  8. @jareware jareware revised this gist Jul 25, 2013. 1 changed file with 33 additions and 1 deletion.
    34 changes: 33 additions & 1 deletion SCSS.md
    Original file line number Diff line number Diff line change
    @@ -540,7 +540,6 @@ Notice how only the last property (`color`) is different. As we define more typ
    color: black;
    }
    ```

    Finally, selector extension allows for integrations into 3rd party CSS libraries, that need not be specifically designed for extension, or even be written in SCSS. [Twitter Bootstrap](http://twitter.github.io/bootstrap/), for example, includes nice styling for buttons, but doesn't apply it to `<button>` elements by default. In our quest to reduce unnecessary CSS classes, we can fix this simply with:
    ```scss
    @import "bootstrap.scss"; // just a renamed .css file, so that @import works
    @@ -553,4 +552,37 @@ This will add the `button` selector into the Bootstrap source wherever `.btn` is

    ## Placeholder selectors

    Because in the above example(s) the `.animal` base class isn't really used anywhere directly, having such a superfluous class name in the CSS output may seem unnecessary. SCSS allows you to overcome this with [placeholder selectors](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#placeholders) - whereas `.foo` signifies a class, and `#foo` an ID, `%foo` is considered a placeholder, and gets special treatment by the parser: its styles are never output on their own, only through extension.
    ```scss
    %animal {
    background: gray;
    // and so on...
    }
    .cat {
    @extend %animal;
    color: white;
    }
    .dog {
    @extend %animal;
    color: black;
    }
    ```
    ```css
    /* compiled CSS */
    .cat, .dog {
    background: gray;
    }
    .cat {
    color: white;
    }
    .dog {
    color: black;
    }
    ```
    Because `%animal` was just a placeholder selector, it's disappeared from the output. As an added benefit, if you never define a selector that extends `%animal`, its styles (`background: gray;` and so on) are completely omitted. This can be very useful in SCSS framework authoring, as you can offer any number of base classes for opt-in extension, but only the ones actually *used* are output into the resulting CSS.

    Placeholder selectors can actually do even more than this, namely expanding the `%placeholder` part into a more complex selector during `@extend`, but personally I've never had to use this feature. The interested reader can check out the [docs on the subject](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#placeholders).
    ## Selector multiple inheritance
    TODO
  9. @jareware jareware revised this gist Jul 25, 2013. 1 changed file with 69 additions and 5 deletions.
    74 changes: 69 additions & 5 deletions SCSS.md
    Original file line number Diff line number Diff line change
    @@ -443,7 +443,7 @@ p {

    ## Extending selectors

    SCSS allows [extending selectors](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#extend) by combining them in the CSS output. Interestingly, while the mechanism is (obviously) very different, the semantics of `@extend` are very analogous to traditional object-oriented languages such as Java:
    SCSS allows [extending selectors](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#extend), by copying and combining selectors in the CSS output. Interestingly, while the mechanism is (obviously) very different, the semantics of `@extend` are quite analogous to traditional object-oriented programming languages (such as Java & whatnot):
    ```scss
    .animal {
    background: gray;
    @@ -462,20 +462,84 @@ SCSS allows [extending selectors](http://sass-lang.com/docs/yardoc/file.SASS_REF
    color: white;
    }
    ```
    That is, `.cat` has all the properties of its "parent class" `.animal`, plus any specific ones it adds or overrides. Classical inheritance, right? Overriding properties in the "child class" works due to the style cascade in the browser: styling that comes later in the file always wins over the styling that came before it (unless of course the combined selectors have differing [specificity](http://www.w3.org/TR/css3-selectors/#specificity)). Extending selectors is often preferable to using mixins to achieve the same effect:
    That is, `.cat` has all the properties of its "parent class" `.animal`, plus any specific ones it adds or overrides. Whereas in normal CSS you would have to reference both the extending class and the parent class (e.g. `<div class="animal cat"></div>`), now you can only name the exact class you want, regardless of what it inherits from (`<div class="cat"></div>`).

    Classical inheritance, right? Overriding properties in the "child class" works due to the style cascade in the browser: styling that comes later in the file always wins over the styling that came before it (unless the combined selectors have differing [specificity](http://www.w3.org/TR/css3-selectors/#specificity), which is something to watch out for when extending selectors). Extending selectors may often be preferable to using mixins to achieve the same effect:
    ```scss
    @mixin animal {
    background: gray;
    border: 1px solid red;
    font-weight: bold;
    font-size: 50px;
    color: red;
    padding: 20px;
    }
    .animal {
    .cat {
    @include animal;
    color: white;
    }
    .cat {
    .dog {
    @include animal;
    color: black;
    }
    ```
    ```css
    /* compiled CSS */
    .cat {
    background: gray;
    border: 1px solid red;
    font-weight: bold;
    font-size: 50px;
    color: red;
    padding: 20px;
    color: white;
    }
    .dog {
    background: gray;
    border: 1px solid red;
    font-weight: bold;
    font-size: 50px;
    color: red;
    padding: 20px;
    color: black;
    }
    ```
    Notice how only the last property (`color`) is different. As we define more types of animals, the amount of repeated style properties keeps growing. This is in contrast to how selector extension would solve the same problem:
    ```scss
    .animal {
    background: gray;
    border: 1px solid red;
    font-weight: bold;
    font-size: 50px;
    color: red;
    padding: 20px;
    }
    .cat {
    @extend .animal;
    color: white;
    }
    .dog {
    @extend .animal;
    color: black;
    }
    ```
    ```css
    /* compiled CSS */
    .animal, .cat, .dog {
    background: gray;
    border: 1px solid red;
    font-weight: bold;
    font-size: 50px;
    color: red;
    padding: 20px;
    }
    .cat {
    color: white;
    }
    .dog {
    color: black;
    }
    ```
    In a non-contrived example, the base `.animal` styling would be more complex, and all properties that the mixin emits would be repeated in the resulting CSS, as many times as the mixin is used. In contrast, selector extension allows each style block to be output just once, but with all necessary selectors included.

    Finally, selector extension allows for integrations into 3rd party CSS libraries, that need not be specifically designed for extension, or even be written in SCSS. [Twitter Bootstrap](http://twitter.github.io/bootstrap/), for example, includes nice styling for buttons, but doesn't apply it to `<button>` elements by default. In our quest to reduce unnecessary CSS classes, we can fix this simply with:
    ```scss
  10. @jareware jareware revised this gist Jun 28, 2013. 1 changed file with 44 additions and 2 deletions.
    46 changes: 44 additions & 2 deletions SCSS.md
    Original file line number Diff line number Diff line change
    @@ -441,9 +441,51 @@ p {
    }
    ```

    ## Extending classes
    ## Extending selectors

    ...with multiple inheritance.
    SCSS allows [extending selectors](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#extend) by combining them in the CSS output. Interestingly, while the mechanism is (obviously) very different, the semantics of `@extend` are very analogous to traditional object-oriented languages such as Java:
    ```scss
    .animal {
    background: gray;
    }
    .cat {
    @extend .animal;
    color: white;
    }
    ```
    ```css
    /* compiled CSS */
    .animal, .cat {
    background: gray;
    }
    .cat {
    color: white;
    }
    ```
    That is, `.cat` has all the properties of its "parent class" `.animal`, plus any specific ones it adds or overrides. Classical inheritance, right? Overriding properties in the "child class" works due to the style cascade in the browser: styling that comes later in the file always wins over the styling that came before it (unless of course the combined selectors have differing [specificity](http://www.w3.org/TR/css3-selectors/#specificity)). Extending selectors is often preferable to using mixins to achieve the same effect:
    ```scss
    @mixin animal {
    background: gray;
    }
    .animal {
    @include animal;
    }
    .cat {
    @include animal;
    color: white;
    }
    ```
    In a non-contrived example, the base `.animal` styling would be more complex, and all properties that the mixin emits would be repeated in the resulting CSS, as many times as the mixin is used. In contrast, selector extension allows each style block to be output just once, but with all necessary selectors included.

    Finally, selector extension allows for integrations into 3rd party CSS libraries, that need not be specifically designed for extension, or even be written in SCSS. [Twitter Bootstrap](http://twitter.github.io/bootstrap/), for example, includes nice styling for buttons, but doesn't apply it to `<button>` elements by default. In our quest to reduce unnecessary CSS classes, we can fix this simply with:
    ```scss
    @import "bootstrap.scss"; // just a renamed .css file, so that @import works

    button {
    @extend .btn;
    }
    ```
    This will add the `button` selector into the Bootstrap source wherever `.btn` is referenced.

    ## Placeholder selectors

  11. @jareware jareware revised this gist Jun 15, 2013. 1 changed file with 8 additions and 16 deletions.
    24 changes: 8 additions & 16 deletions SCSS.md
    Original file line number Diff line number Diff line change
    @@ -394,18 +394,14 @@ This pattern can be useful in any library code that outputs nontrivial styling w

    ## Media query bubbling

    `@media` blocks
    `@media` blocks do not need to be declared at the root level of the stylesheet:
    ```scss
    p {
    @media (max-width: 768px) {
    // Use larger text for smaller screens:
    font-size: 150%;
    font-size: 150%; // use larger text for smaller screens
    }
    }
    ```

    Compiles into:

    ```css
    /* compiled CSS */
    @media (max-width: 768px) {
    @@ -414,27 +410,23 @@ Compiles into:
    }
    }
    ```
    Notice how the compiler "bubbles up" the `@media` block to the root level (since regular CSS doesn't support selector nesting), and then outputs within all styling and the corresponding selectors that were encountered within the `@media` block in the SCSS source.
    This is very useful as it allows you to make media-specific tweaks almost anywhere in your styling, right where they're relevant, instead of collecting all those tweaks to the end of the stylesheet, and hoping that their selectors will stay in sync with the ones they're overriding (they won't).

    ## Media query nesting

    The aforementioned bubbling mechanism also takes nesting into account, and combines all applicable queries with the `and` media query operator:
    ```scss
    p {
    @media (max-width: 768px) {

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

    font-size: 150%; // use larger text for smaller screens
    @media (orientation: landscape) {

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

    Compiles into:

    ```css
    /* compiled CSS */
    @media (max-width: 768px) {
  12. @jareware jareware revised this gist Jun 15, 2013. 1 changed file with 65 additions and 3 deletions.
    68 changes: 65 additions & 3 deletions SCSS.md
    Original file line number Diff line number Diff line change
    @@ -287,7 +287,7 @@ Personally, I have yet to find a use case for this, but [the documentation](http
    ## Content block arguments for mixins
    Since version [3.2.0](http://sass-lang.com/docs/yardoc/file.SASS_CHANGELOG.html#320_10_august_2012), 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:
    Since [version 3.2.0](http://sass-lang.com/docs/yardoc/file.SASS_CHANGELOG.html#320_10_august_2012), 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:
    ```scss
    @mixin only-for-mobile {
    @@ -296,7 +296,7 @@ Since version [3.2.0](http://sass-lang.com/docs/yardoc/file.SASS_CHANGELOG.html#
    }
    }
    @include only-for-mobile() /* @content begins */ {
    @include only-for-mobile() /* note: @content begins here */ {
    p {
    font-size: 150%;
    }
    @@ -329,10 +329,72 @@ This is a very powerful language feature. You can mix standard and content bloc
    ## 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:
    ```scss
    @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:
    ```scss
    @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:
    ```scss
    @mixin message($class) {
    .message-#{$class} {
    border: 1px dotted yellow;
    color: yellow;
    margin: 20px;
    padding: 10px;
    @content;
    }
    }

    @include message("subtle") {
    margin: 5px;
    }
    ```
    ```css
    /* 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:
    ```scss
    @include message("actionable") {
    button {
    float: right;
    }
    }
    ```
    ```css
    /* 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
    ```scss
    p {
    @media (max-width: 768px) {
  13. @jareware jareware revised this gist Jun 15, 2013. 1 changed file with 20 additions and 21 deletions.
    41 changes: 20 additions & 21 deletions SCSS.md
    Original file line number Diff line number Diff line change
    @@ -10,7 +10,7 @@

    ## Prefixing parent selector references

    The familiar way:
    This is the familiar way:
    ```scss
    a {
    &:hover {
    @@ -38,7 +38,7 @@ 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 `no-touch` class are often applied in such a way, to the `<body>` element for example.
    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](http://modernizr.com/docs/) `no-touch` class are often applied this way to the `<body>` element.

    ## Variable interpolation in selectors

    @@ -58,7 +58,7 @@ p.message-error {
    ```
    ...or almost anywhere else for that matter, like in media queries or CSS comments:
    ```scss
    $breakpoint: 768px; // this would likely go to a _settings.scss somewhere
    $breakpoint: 768px;

    @media (max-width: #{$breakpoint}) {
    /* This block only applies to viewports <= #{$breakpoint} wide... */
    @@ -71,6 +71,8 @@ $breakpoint: 768px; // this would likely go to a _settings.scss somewhere
    }
    ```

    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:
    @@ -107,7 +109,7 @@ This is how many SCSS modules (including most that ship with Compass) are config

    SCSS sports the standard set of flow control directives, such as `if`:
    ```scss
    $debug: false; // this would likely be in a _settings.scss somewhere
    $debug: false; // TODO: move to _settings.scss

    article {
    color: black;
    @@ -125,7 +127,7 @@ article {
    ```
    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 things, like:
    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:
    ```scss
    @each $name in 'save' 'cancel' 'help' {
    .icon-#{$name} {
    @@ -147,13 +149,13 @@ There's also `@for`, `@each` and `@while`. They're good for a number of things,
    ```
    ...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 the subject](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#control_directives).
    The interested reader can check out the [full documentation on control directives](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#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](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#lists) of the SCSS language, but a quick demo of their application might be configuring some generated styling:
    ```scss
    $buttonConfig: 'save' 50px, 'cancel' 50px, 'help' 100px;
    $buttonConfig: 'save' 50px, 'cancel' 50px, 'help' 100px; // TODO: move to _settings.scss
    @each $tuple in $buttonConfig {
    .button-#{nth($tuple, 1)} {
    @@ -177,7 +179,7 @@ This demonstrates two features of the list data type, namely the `nth()` [list a
    ```js
    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 arrays.
    That is, lists can be separated by both spaces and commas, and alternation between the two notations produces nested lists.
    ## Defining custom functions
    @@ -198,11 +200,11 @@ p {
    ```
    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 it by giving it a name. SCSS ships with a ton of [useful built-in functions](http://sass-lang.com/docs/yardoc/Sass/Script/Functions.html), and Compass [adds even more](http://compass-style.org/reference/compass/helpers/), so do first check whether there's a built-in equivalent before implementing your own helper.
    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](http://sass-lang.com/docs/yardoc/Sass/Script/Functions.html), and Compass [adds even more](http://compass-style.org/reference/compass/helpers/), 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 *final* 0-N arguments can be made optional by providing them with a default value:
    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:

    ```scss
    @mixin foobar($a, $b, $padding: 20px) {
    @@ -221,7 +223,7 @@ p.important {

    ## 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:
    If your mixin (or function) takes *a lot* of arguments, there's a similar call-time syntax for selecting only specific arguments to override:
    ```scss
    @mixin foobar($topPadding: 10px, $rightPadding: 20px, $bottomPadding: 10px, $leftPadding: 20px, $evenMorePadding: 10px) {
    @@ -233,7 +235,7 @@ p {
    }
    ```
    In cases where a lot of the arguments are just for overriding specific style properties, however, the "content block overrides -pattern" may work a lot better (see below).
    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
    @@ -247,8 +249,7 @@ In cases where a lot of the arguments are just for overriding specific style pro
    }
    }
    }
    @include config-icon-colors(
    'icon-',
    @include config-icon-colors('icon-',
    'save' green,
    'cancel' gray,
    'delete' red
    @@ -267,13 +268,13 @@ In cases where a lot of the arguments are just for overriding specific style pro
    }
    ```
    The above helper could be used to set up colors for your font icons, [Font Awesome](http://fortawesome.github.io/Font-Awesome/) for example. It 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" ]`).
    The above helper could be used to set up colors for your font icons, [Font Awesome](http://fortawesome.github.io/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" ]`).
    The `...` syntax in fact also works during call-time. When used this way, it expands a list into separate arguments, to be fed into the target mixin:
    In fact, the `...` syntax also works during call-time, where it expands a list into separate arguments, to be fed into the target mixin:
    ```scss
    @mixin foobar($a, $b, $c) {
    // receives args $a = 5px, $b = red and so on
    // receives args $a = 5px, $b = red, and so on
    }
    $myArgs: 5px red "bla bla";
    @@ -286,7 +287,7 @@ Personally, I have yet to find a use case for this, but [the documentation](http
    ## Content block arguments for mixins
    Since version TODO, 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:
    Since version [3.2.0](http://sass-lang.com/docs/yardoc/file.SASS_CHANGELOG.html#320_10_august_2012), 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:
    ```scss
    @mixin only-for-mobile {
    @@ -310,9 +311,7 @@ Since version TODO, SCSS has had an implicit mixin argument accessible through t
    }
    ```
    This is a very powerful feature. You can mix standard and content block arguments, too:
    TODO
    This is a very powerful language feature. You can mix standard and content block arguments, too:
    ```scss
    @mixin only-for-mobile($breakpoint) {
  14. @jareware jareware revised this gist Jun 15, 2013. 1 changed file with 48 additions and 3 deletions.
    51 changes: 48 additions & 3 deletions SCSS.md
    Original file line number Diff line number Diff line change
    @@ -237,7 +237,52 @@ In cases where a lot of the arguments are just for overriding specific style pro
    ## Variable arguments for functions/mixins
    TODO: ...and expanding and/or extending during further calls.
    [Var-args](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#variable_arguments) 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:
    ```scss
    @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
    );
    ```
    ```css
    /* 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](http://fortawesome.github.io/Font-Awesome/) for example. It 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" ]`).
    The `...` syntax in fact also works during call-time. When used this way, it expands a list into separate arguments, to be fed into the target mixin:
    ```scss
    @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](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#variable_arguments) has a nice use case for passing current arguments forward to another mixin.
    ## Content block arguments for mixins
    @@ -250,11 +295,11 @@ Since version TODO, SCSS has had an implicit mixin argument accessible through t
    }
    }
    @include only-for-mobile() /* content begins */ {
    @include only-for-mobile() /* @content begins */ {
    p {
    font-size: 150%;
    }
    } /* content ends */
    } /* @content ends */
    ```
    ```css
    /* compiled CSS */
  15. @jareware jareware revised this gist Jun 11, 2013. 1 changed file with 21 additions and 13 deletions.
    34 changes: 21 additions & 13 deletions SCSS.md
    Original file line number Diff line number Diff line change
    @@ -200,25 +200,28 @@ 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 it by giving it a name. SCSS ships with a ton of [useful built-in functions](http://sass-lang.com/docs/yardoc/Sass/Script/Functions.html), and Compass [adds even more](http://compass-style.org/reference/compass/helpers/), so do first check whether there's a built-in equivalent before implementing your own helper.

    ## Argument defaults for functions/mixins
    ## Argument defaults

    Arguments and functions support default values for arguments; the *final* 0-N arguments can be made optional by providing them with a default value:

    ```scss
    @mixin foobar($a, $b, $padding: 20px) {
    // do something with all these arguments...
    padding: $padding;
    // ...and something with $a and $b
    }

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

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

    ## Keyword arguments

    If you have a huge helper with:
    If your mixin (or function) takes a lot of arguments, there's a similar call-time syntax for selecting only specific arguments to override:
    ```scss
    @mixin foobar($topPadding: 10px, $rightPadding: 20px, $bottomPadding: 10px, $leftPadding: 20px, $evenMorePadding: 10px) {
    @@ -230,30 +233,29 @@ p {
    }
    ```
    Note the `@include mixin() { overrides; }` pattern too.
    In cases where a lot of the arguments are just for overriding specific style properties, however, the "content block overrides -pattern" may work a lot better (see below).
    ## Variable arguments for functions/mixins
    ...and expanding and/or extending during further calls.
    TODO: ...and expanding and/or extending during further calls.
    ## Content block arguments for mixins
    Since version TODO, 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:
    ```scss
    @mixin only-for-mobile {
    @media (max-width: 768px) {
    @content;
    }
    }
    @include only-for-mobile {
    @include only-for-mobile() /* content begins */ {
    p {
    font-size: 150%;
    }
    }
    } /* content ends */
    ```

    Compiles into:

    ```css
    /* compiled CSS */
    @media (max-width: 768px) {
    @@ -263,7 +265,9 @@ Compiles into:
    }
    ```
    You can mix standard and content block arguments, too:
    This is a very powerful feature. You can mix standard and content block arguments, too:
    TODO
    ```scss
    @mixin only-for-mobile($breakpoint) {
    @@ -279,6 +283,10 @@ You can mix standard and content block arguments, too:
    }
    ```
    ## Content block overrides -pattern
    ...
    ## Media query bubbling
    ```scss
  16. @jareware jareware revised this gist May 25, 2013. 1 changed file with 9 additions and 19 deletions.
    28 changes: 9 additions & 19 deletions SCSS.md
    Original file line number Diff line number Diff line change
    @@ -177,38 +177,28 @@ This demonstrates two features of the list data type, namely the `nth()` [list a
    ```js
    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 is also allowed.
    ## Color arithmetic
    TODO
    ## Math (and other) functions
    http://sass-lang.com/docs/yardoc/Sass/Script/Functions.html
    That is, lists can be separated by both spaces and commas, and alternation between the two notations produces nested arrays.
    ## Defining custom functions
    No Ruby needed:
    [Mixins](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#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](http://sass-lang.com/docs/yardoc/Sass/Script/Functions.html#adding_custom_functions):
    ```scss
    @function make-more-spacious($value) {
    @return $value + 20px;
    @function make-greener($value) {
    @return $value + rgb(0,50,0); // arithmetic with colors is _b
    }
    p {
    margin: make-more-spacious(50px);
    background: make-greener(gray);
    }
    ```
    Compiles into:
    ```css
    /* compiled CSS */
    p {
    margin: 70px;
    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 it by giving it a name. SCSS ships with a ton of [useful built-in functions](http://sass-lang.com/docs/yardoc/Sass/Script/Functions.html), and Compass [adds even more](http://compass-style.org/reference/compass/helpers/), so do first check whether there's a built-in equivalent before implementing your own helper.

    ## Argument defaults for functions/mixins

  17. @jareware jareware revised this gist May 20, 2013. 1 changed file with 87 additions and 26 deletions.
    113 changes: 87 additions & 26 deletions SCSS.md
    Original file line number Diff line number Diff line change
    @@ -10,73 +10,60 @@

    ## Prefixing parent selector references

    Familiar way:

    The familiar way:
    ```scss
    a {
    &:hover {
    color: red;
    }
    }
    ```
    Compiles into:
    ```css
    /* compiled CSS */
    a:hover {
    color: red;
    }
    ```

    But can be used with a prefix just as well:

    But `&` can be used with a prefix just as well:
    ```scss
    p {
    body.no-touch & {
    display: none;
    }
    }
    ```

    Gives you:

    ```css
    /* 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 `no-touch` class are often applied in such a way, to the `<body>` element for example.

    ## Variable interpolation in selectors

    Variables can be expanded in selectors, too:
    ```scss
    $alertClass: "error";

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

    Compiles into:

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

    ...or almost anywhere else, for that matter.

    ...or almost anywhere else for that matter, like in media queries or CSS comments:
    ```scss
    $breakpoint: 768px; // this would likely go to a _settings.scss somewhere

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

    Compiles into:

    ```css
    /* compiled CSS */
    @media (max-width: 768px) {
    @@ -86,37 +73,111 @@ Compiles into:

    ## Variable defaults

    TODO
    If your SCSS module can be configured using globals (which tends to be the SCSS way), you can declare them with a default value:
    ```scss
    // _my-module.scss:
    $message-color: blue !default;

    p.message {
    color: $message-color;
    }
    ```
    ```css
    /* compiled CSS */
    p.message {
    color: blue;
    }
    ```
    But you can then optionally override the module defaults before its inclusion:
    ```scss
    $message-color: black;
    @import 'my-module';
    ```
    ```css
    /* 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`:
    ```scss
    $debug: false; // this would likely be in a _settings.scss somewhere

    article {

    color: black;

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

    Compiles into:

    ```css
    /* 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`.
    There's also `@for`, `@each` and `@while`. They're good for a number of things, like:
    ```scss
    @each $name in 'save' 'cancel' 'help' {
    .icon-#{$name} {
    background-image: url('/images/#{$name}.png');
    }
    }
    ```
    ```css
    /* 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 the subject](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#control_directives).
    ## The list data type
    TODO
    As we saw in the previous example, `@each` can iterate over a list. Lists are in fact a [fundamental part](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#lists) of the SCSS language, but a quick demo of their application might be configuring some generated styling:
    ```scss
    $buttonConfig: 'save' 50px, 'cancel' 50px, 'help' 100px;
    @each $tuple in $buttonConfig {
    .button-#{nth($tuple, 1)} {
    width: nth($tuple, 2);
    }
    }
    ```
    ```css
    /* 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](http://sass-lang.com/docs/yardoc/Sass/Script/Functions.html#nth-instance_method), and more interestingly list nestability: in JavaScript notation, the above would be equivalent to:
    ```js
    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 is also allowed.
    ## Color arithmetic
  18. @jareware jareware revised this gist Mar 28, 2013. 1 changed file with 51 additions and 48 deletions.
    99 changes: 51 additions & 48 deletions SCSS.md
    Original file line number Diff line number Diff line change
    @@ -46,43 +46,32 @@ body.no-touch p {
    }
    ```

    ## Media query bubbling
    ## Variable interpolation in selectors

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

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

    Compiles into:

    ```css
    /* compiled CSS */
    @media (max-width: 768px) {
    p {
    font-size: 150%;
    }
    p.message-error {
    color: red;
    }
    ```

    ## Media query nesting
    ...or almost anywhere else, for that matter.

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

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

    @media (orientation: landscape) {
    $breakpoint: 768px; // this would likely go to a _settings.scss somewhere

    // Condense text a bit because of small vertical space:
    line-height: 75%;
    }
    }
    @media (max-width: #{$breakpoint}) {
    /* This block only applies to viewports <= #{$breakpoint} wide... */
    }
    ```

    @@ -91,17 +80,14 @@ Compiles into:
    ```css
    /* compiled CSS */
    @media (max-width: 768px) {
    p {
    font-size: 150%;
    }
    }
    @media (max-width: 768px) and (orientation: landscape) {
    p {
    line-height: 75%;
    }
    /* This block only applies to viewports <= 768px wide... */
    }
    ```

    ## Variable defaults

    TODO

    ## Control directives

    ```scss
    @@ -208,8 +194,8 @@ Note the `@include mixin() { overrides; }` pattern too.
    }
    }

    p {
    @include only-for-mobile {
    @include only-for-mobile {
    p {
    font-size: 150%;
    }
    }
    @@ -235,39 +221,50 @@ You can mix standard and content block arguments, too:
    }
    }

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

    ## Variable interpolation in selectors
    ## Media query bubbling

    ```scss
    $alertClass: "error";

    p.message-#{$alertClass} {
    color: red;
    p {
    @media (max-width: 768px) {
    // Use larger text for smaller screens:
    font-size: 150%;
    }
    }
    ```

    Compiles into:

    ```css
    /* compiled CSS */
    p.message-error {
    color: red;
    @media (max-width: 768px) {
    p {
    font-size: 150%;
    }
    }
    ```

    ...or almost anywhere else, for that matter.
    ## Media query nesting

    ```scss
    $breakpoint: 768px; // this would likely go to a _settings.scss somewhere
    p {
    @media (max-width: 768px) {

    @media (max-width: #{$breakpoint}) {
    /* This block only applies to viewports <= #{$breakpoint} wide... */
    // Use larger text for smaller screens:
    font-size: 150%;

    @media (orientation: landscape) {

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

    @@ -276,15 +273,21 @@ Compiles into:
    ```css
    /* compiled CSS */
    @media (max-width: 768px) {
    /* This block only applies to viewports <= 768px wide... */
    p {
    font-size: 150%;
    }
    }
    @media (max-width: 768px) and (orientation: landscape) {
    p {
    line-height: 75%;
    }
    }
    ```

    ## Variable defaults

    ## Extending classes

    ...with multiple inheritance.

    ## Placeholder selectors

    TODO
  19. @jareware jareware revised this gist Mar 27, 2013. 1 changed file with 7 additions and 5 deletions.
    12 changes: 7 additions & 5 deletions SCSS.md
    Original file line number Diff line number Diff line change
    @@ -145,12 +145,12 @@ http://sass-lang.com/docs/yardoc/Sass/Script/Functions.html
    No Ruby needed:

    ```scss
    @function add-padding($toValue) {
    @return $toValue + 20px;
    @function make-more-spacious($value) {
    @return $value + 20px;
    }

    p {
    margin: add-padding(50px);
    margin: make-more-spacious(50px);
    }
    ```

    @@ -184,15 +184,17 @@ p.important {
    If you have a huge helper with:

    ```scss
    @mixin foobar($a: 1px, $b: 2px, $c: 3px, $d: 4px, $e: 5px) {
    @mixin foobar($topPadding: 10px, $rightPadding: 20px, $bottomPadding: 10px, $leftPadding: 20px, $evenMorePadding: 10px) {
    // do something with all these arguments...
    }

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

    Note the `@include mixin() { overrides; }` pattern too.

    ## Variable arguments for functions/mixins

    ...and expanding and/or extending during further calls.
  20. @jareware jareware revised this gist Mar 27, 2013. 1 changed file with 34 additions and 0 deletions.
    34 changes: 34 additions & 0 deletions SCSS.md
    Original file line number Diff line number Diff line change
    @@ -242,8 +242,42 @@ p {

    ## Variable interpolation in selectors

    ```scss
    $alertClass: "error";

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

    Compiles into:

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

    ...or almost anywhere else, for that matter.

    ```scss
    $breakpoint: 768px; // this would likely go to a _settings.scss somewhere

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

    Compiles into:

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

    ## Variable defaults

    ## Extending classes
  21. @jareware jareware revised this gist Mar 1, 2013. 1 changed file with 41 additions and 0 deletions.
    41 changes: 41 additions & 0 deletions SCSS.md
    Original file line number Diff line number Diff line change
    @@ -199,6 +199,47 @@ p {

    ## Content block arguments for mixins

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

    p {
    @include only-for-mobile {
    font-size: 150%;
    }
    }
    ```

    Compiles into:

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

    You can mix standard and content block arguments, too:

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

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

    ## Variable interpolation in selectors

    ...or almost anywhere else, for that matter.
  22. @jareware jareware revised this gist Mar 1, 2013. 1 changed file with 41 additions and 10 deletions.
    51 changes: 41 additions & 10 deletions SCSS.md
    Original file line number Diff line number Diff line change
    @@ -128,6 +128,14 @@ article {

    There's also `@for`, `@each` and `@while`.

    ## The list data type

    TODO

    ## Color arithmetic

    TODO

    ## Math (and other) functions

    http://sass-lang.com/docs/yardoc/Sass/Script/Functions.html
    @@ -155,28 +163,51 @@ p {
    }
    ```

    ## The list data type

    ## Color arithmetic
    ## Argument defaults for functions/mixins

    ## Keyword arguments
    ```scss
    @mixin foobar($a, $b, $padding: 20px) {
    // do something with all these arguments...
    }

    ## Variable interpolation in selectors
    p {
    @include foobar(123, "abc");
    }

    ...or almost anywhere else, for that matter.
    p.important {
    @include foobar(123, "abc", 50px);
    }
    ```

    ## Variable defaults
    ## Keyword arguments

    ## Extending classes
    If you have a huge helper with:

    ...with multiple inheritance.
    ```scss
    @mixin foobar($a: 1px, $b: 2px, $c: 3px, $d: 4px, $e: 5px) {
    // do something with all these arguments...
    }

    ## Argument defaults for functions/mixins
    p {
    @include foobar($c: 50px); // specify only the argument you want to override
    }
    ```

    ## Variable arguments for functions/mixins

    ...and expanding and/or extending during further calls.

    ## Content block arguments for mixins

    ## Variable interpolation in selectors

    ...or almost anywhere else, for that matter.

    ## Variable defaults

    ## Extending classes

    ...with multiple inheritance.

    ## Placeholder selectors

  23. @jareware jareware revised this gist Mar 1, 2013. 1 changed file with 23 additions and 0 deletions.
    23 changes: 23 additions & 0 deletions SCSS.md
    Original file line number Diff line number Diff line change
    @@ -130,8 +130,31 @@ There's also `@for`, `@each` and `@while`.

    ## Math (and other) functions

    http://sass-lang.com/docs/yardoc/Sass/Script/Functions.html

    ## Defining custom functions

    No Ruby needed:

    ```scss
    @function add-padding($toValue) {
    @return $toValue + 20px;
    }

    p {
    margin: add-padding(50px);
    }
    ```

    Compiles into:

    ```css
    /* compiled CSS */
    p {
    margin: 70px;
    }
    ```

    ## The list data type

    ## Color arithmetic
  24. @jareware jareware revised this gist Mar 1, 2013. 1 changed file with 30 additions and 6 deletions.
    36 changes: 30 additions & 6 deletions SCSS.md
    Original file line number Diff line number Diff line change
    @@ -102,12 +102,40 @@ Compiles into:
    }
    ```

    ## The list data type
    ## Control directives

    ## Color arithmetic
    ```scss
    $debug: false; // this would likely be in a _settings.scss somewhere

    article {

    color: black;

    @if ($debug) {
    border: 1px dotted red;
    }
    }
    ```

    Compiles into:

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

    There's also `@for`, `@each` and `@while`.

    ## Math (and other) functions

    ## Defining custom functions

    ## The list data type

    ## Color arithmetic

    ## Keyword arguments

    ## Variable interpolation in selectors
    @@ -120,8 +148,6 @@ Compiles into:

    ...with multiple inheritance.

    ## Control directives

    ## Argument defaults for functions/mixins

    ## Variable arguments for functions/mixins
    @@ -130,6 +156,4 @@ Compiles into:

    ## Content block arguments for mixins

    ## Math (and other) functions

    ## Placeholder selectors
  25. @jareware jareware revised this gist Mar 1, 2013. 1 changed file with 52 additions and 0 deletions.
    52 changes: 52 additions & 0 deletions SCSS.md
    Original file line number Diff line number Diff line change
    @@ -48,8 +48,60 @@ body.no-touch p {

    ## Media query bubbling

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

    Compiles into:

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

    ## Media query nesting

    ```scss
    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%;
    }
    }
    }
    ```

    Compiles into:

    ```css
    /* compiled CSS */
    @media (max-width: 768px) {
    p {
    font-size: 150%;
    }
    }
    @media (max-width: 768px) and (orientation: landscape) {
    p {
    line-height: 75%;
    }
    }
    ```

    ## The list data type

    ## Color arithmetic
  26. @jareware jareware revised this gist Mar 1, 2013. 1 changed file with 41 additions and 6 deletions.
    47 changes: 41 additions & 6 deletions SCSS.md
    Original file line number Diff line number Diff line change
    @@ -8,10 +8,48 @@
    * [Variables](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#variables_)
    * [Mixins](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#mixins)

    ## Placeholder selectors

    ## Prefixing parent selector references

    Familiar way:

    ```scss
    a {
    &:hover {
    color: red;
    }
    }
    ```
    Compiles into:
    ```css
    /* compiled CSS */
    a:hover {
    color: red;
    }
    ```

    But can be used with a prefix just as well:

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

    Gives you:

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

    ## Media query bubbling

    ## Media query nesting

    ## The list data type

    ## Color arithmetic
    @@ -26,10 +64,6 @@

    ## Variable defaults

    ## Media query bubbling

    ## Media query nesting

    ## Extending classes

    ...with multiple inheritance.
    @@ -46,3 +80,4 @@

    ## Math (and other) functions

    ## Placeholder selectors
  27. @jareware jareware revised this gist Feb 28, 2013. 1 changed file with 48 additions and 1 deletion.
    49 changes: 48 additions & 1 deletion SCSS.md
    Original file line number Diff line number Diff line change
    @@ -1 +1,48 @@
    TODO
    # 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:

    * [Nested selectors](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#css_extensions)
    * [Variables](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#variables_)
    * [Mixins](http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#mixins)

    ## Placeholder selectors

    ## Prefixing parent selector references

    ## The list data type

    ## Color arithmetic

    ## Defining custom functions

    ## Keyword arguments

    ## Variable interpolation in selectors

    ...or almost anywhere else, for that matter.

    ## Variable defaults

    ## Media query bubbling

    ## Media query nesting

    ## Extending classes

    ...with multiple inheritance.

    ## Control directives

    ## Argument defaults for functions/mixins

    ## Variable arguments for functions/mixins

    ...and expanding and/or extending during further calls.

    ## Content block arguments for mixins

    ## Math (and other) functions

  28. @jareware jareware created this gist Feb 8, 2013.
    1 change: 1 addition & 0 deletions SCSS.md
    Original file line number Diff line number Diff line change
    @@ -0,0 +1 @@
    TODO