.SHARP{C#DERS}

If you are someone who spends a great amount of their day writing CSS then I am sure you have dabbled in LESS or SASS at least a time or two. While they do offer dynamic solutions to writing CSS I have noticed a more annoying trend that has popped up from them as well. Lazy coding. Excessive nesting and overuse and improper use of variables and mixins has turned these environments into environments that produce bloated code. I have assembles a few general rules I try and follow when writing in either language. In this post I am going to focus on understanding the simple aspects of working with these languages. Ideally, this will help you produce more fluid code that is more simplistic, and easier to manage.

Before we get started just know that the code I use in the examples below is LESS but migrating them into SASS can be done with minimal effort if you have a general understanding of the language.

LESS and SASS make nesting elements a much more manageable task. That does not mean your CSS should have elements nested 4 or 5 levels deep. If you really dig around many of the brightest CSS minds will tell you that anything greater than 3 levels of nesting is the point in which your code can really bog down. In any case, we should all do our best to avoid nesting all together.

Let’s say you are styling a blog post. A quick way to write the LESS for this without thinking much about it would be something like the example below.

.content-wrapper { 
    margin: 1.5em; 
    border: .0625em solid #333; 
    font-size: 1em; 
    color: #242424;

    .content-title { 
        padding-bottom: .5em; 
        font-size: 2em; 
        color: #176ba4; 
    }

    .content-article {

        .content-link { 
            font-style: italic; 
            text-decoration: none; 
            color: #3498DB; 
        }

    }

    .content-footer { 
        padding-top: 1em;

        .social-wrapper { 
            padding: 1em; 
            background: #ccc;

            .social-button { 
                display: inline-block; 
                margin-right: .25em; 
            } 
        }

    } 
}

As you can see, we now have a series of elements nested within each other. Each given relatively simple names. At this level, one of the more simplistic levels of a layout, nesting you could say is not a big deal. However, let’s say you want to start adding some complexity to the layout. Perhaps the title now needs an icon next to it, the title itself needs to act as a link, and the content itself needs some added structure to handle images. So let’s add that to our existing code.

.content-wrapper { 
    margin: 1.5em; 
    border: .0625em solid #333; 
    font-size: 1em; 
    color: #242424;

    .content-title { 
        padding-bottom: .5em; 
        font-size: 2em; 
        color: #176ba4;

        .title-icon { 
            display: inline-block; 
            margin-right: .25em; 
            color: #e9982e; 
        }

        .title-link { 
            display: inline-block; 
            color: inherit; 
        } 
    }

    .content-article {

        .content-link { 
            font-style: italic; 
            text-decoration: none; 
            color: #3498DB; 
        }

        .content-photo-wrapper { 
            margin: .25em; 
            padding: .25em; 
            background: #ccc;

            &.left { 
                float: left; 
            }

            &.right { 
                float: right; 
            }

            .content-photo { 
                width: 100%; 
            }

            .photo-caption { 
                display: block; 
                padding: .25em; 
                font-style: italic; 
                color: #777; 
            } 
        }

    }

    .content-footer { 
        padding-top: 1em;

        .social-links { 
            padding: 1em; 
            background: #ccc;

            .social-button { 
                display: inline-block; 
                margin-right: .25em; 
            } 
        }

    } 
}

Quickly those few levels of nesting have become more complex. Additionally the code is not what would be considered Dry CSS. For more on that you can refer to a few links that I have listed below.

• DRYer Vanilla CSS
• DRY CSS talk

Those links aside, let’s get back to our mess which in some ways also addresses utilizing Dry CSS.

Now that our blog posts have become a bit more complex and we have added multiple levels of nesting to our code things begin to get heavy and our code can get quite ugly. Ideally the goal in writing CSS with LESS or SASS should be to avoid nesting at all costs, much like they are in base CSS. In some cases nesting can be very helpful. We will run through some of those scenarios in a moment. For now, let’s take a look at how our code could be cleaner, more efficient, and easier to navigate.

/*---------------------------------------------- 
REUSABLE ITEMS 
-----------------------------------------------*/ 
&.left { 
    float: left; 
}

&.right { 
    float: right; 
}

/*---------------------------------------------- 
CONTENT WRAPPER 
-----------------------------------------------*/ 
.content-wrapper { 
    margin: 1.5em; 
    border: .0625em solid #333; 
    font-size: 1em; 
    color: #242424; 
} 
    
    /*---------------------------------------------- 
    CONTENT TITLE 
    -----------------------------------------------*/ 
    .content-title { 
        padding-bottom: .5em; 
        font-size: 2em; 
        color: #176ba4; 
    }

        /* Content Title -- Icon */ 
        .content-title-icon { 
            display: inline-block; 
            margin-right: .25em; 
            color: #e9982e; 
        }

        /* Content Title -- Link */ 
        .content-title-link { 
            display: inline-block; 
            color: inherit; 
        }

    /*---------------------------------------------- 
    CONTENT ARTICLE 
    -----------------------------------------------*/

        /* Content Article -- Links */ 
        .content-article-link { 
            font-style: italic; 
            text-decoration: none; 
            color: #3498DB; 
        }

        /* Content Article -- Photo Wrapper */ 
        .content-photo-wrapper { 
            margin: .25em; 
            padding: .25em; 
            background: #ccc; 
        }

            /* Content Article -- Photo */ 
            .content-photo { 
                width: 100%; 
            }

            /* Content Article -- Photo Caption */ 
            .content-article-photo-caption { 
                display: block; 
                padding: .25em; 
                font-style: italic; 
                color: #777; 
            }

    /*---------------------------------------------- 
    CONTENT FOOTER 
    -----------------------------------------------*/ 
    .content-footer { 
        padding-top: 1em; 
    }

        /* Content Footer -- Social Links Wrapper */ 
        .content-footer-social-wrapper { 
            padding: 1em; 
            background: #ccc; 
        }

            /* Content Footer -- Social Links Buttons */ 
            .content-footer-social-button { 
                display: inline-block; 
                margin-right: .25em; 
            }

As you can see, the CSS for the blog posts has changed quite a bit. Not only is there no nesting, the code has been given labels and is now much easier to navigate. Right off the bat you see things have been moved around when you discover that the .left and .right classes have been moved outside of the rest of our code. These are styles which might be of some use in other areas of the site which makes them reusable. Why would you want to keep writing these classes again and again when they can be in one centralized location? Also, a few of the classes themselves have been renamed. I don’t support the concept of enormous naming conventions in CSS, but I definitely thinking making these class names as descriptive as they can be is beneficial.

Now that the code is cleaner, commented, and un-nested, let’s talk about the situations in which nesting in the best practice. Pseudo-classes are a case in which nesting makes perfect sense. There is no reason to waste time re-typing our class or ID names. Also, any scenario which we have a class that has a variety of different scenarios in which we are need to change the appearance of our element. A good example of that would be a button. Throughout most websites and applications we have scenarios where buttons need to be red, yellow, green, or well whatever color makes the most sense within the design. A good example of Dry CSS would be to set the base parameters of the button and then address the varying changes in the button descriptors. Let’s review creating a fluid button that can change colors and sizes.

First let’s just create the base of the button.

[class*="button"] { 
    cursor: pointer; 
    margin: 0; 
    padding: 0 1em; 
    background: #dfdfdf; 
    border: none; 
    border-radius: .125em; 
    font-size: 1em; 
    line-height: 1.875em; 
    text-decoration: none; 
    color: #3f3f3f;

    /* Button -- Hover */ 
    &:hover { 
        background: #bfbfbf; 
    }

    /* Button -- Focus */ 
    &:focus { 
        outline: none; 
    } 
}

This is the base of our button. We have assigned our paddings, line-heights, font-sizes and a few other base style properties. If we want to make this button a fluid element so it can be different colors though we need to do some more work. As it stands right now, if the class button is added to an element it will create a grey button. Now let’s add some flexibility through nesting.

[class*="button"] { 
    cursor: pointer; 
    margin: 0; 
    padding: 0 1em; 
    background: #dfdfdf; 
    border: none; 
    border-radius: .125em; 
    font-size: 1em; 
    line-height: 1.875em; 
    text-decoration: none; 
    color: #3f3f3f;

    /* Button -- Hover */ 
    &:hover { 
        background: #bfbfbf; 
    }

    /* Button -- Focus */ 
    &:focus { 
        outline: none; 
    }

    /* Button -- Submit */ 
    &[class*="-submit"] { 
        background: #28B061; 
        color: #fff;

        &:hover { 
            background: darken(#28B061, 15%); 
        } 
    }

    /* Button -- Cancel */ 
    &[class*="-cancel"] { 
        background: #DD6859; 
        color: #fff;

        &:hover { 
            background: darken(#DD6859, 15%); 
        } 
    }

    /* Button -- Edit */ 
    &[class*="-edit"] { 
        background: #E9A92E; 
        color: #fff;

        &:hover { 
            background: darken(#E9A92E, 15%); 
        } 
    }

    /* Button - View */ 
    &[class*="-view"] { 
        background: #3498DB; 
        color: #fff;

        &:hover { 
            background: darken(#3498DB, 15%); 
        } 
    } 
}

With the code above we now have some flexibility in how these buttons appear. Now the button class can change by changing the class from button to button-submit, button–cancel, button–edit, or button–view. The base button will still generate a grey button. Adding any of the –elements above will change the buttons appearance. This however is not completely using the full potential of what LESS can do. These buttons are perfect for creating a mixin (LESS term). We could avoid writing the Pseudo-classes for each type of the button by writing a mixin that handles all of that at the base level. The mixin can also provide the variables for each different variation of how the button will appear. Let’s take a look at how that can be accomplished.

/*----------------------------------------------
BUTTON MIXIN
-----------------------------------------------*/
 .button-background-color() {
    vertical-align: top;
    cursor: pointer;
    margin: 0;
    padding: 0 1em;
    border: none;
    border-radius: .125em;
    font-size: 1em;
    line-height: 1.875em;
    text-decoration: none;
 
    /* Button -- Mixin Variables */
    background: @button-background-color;
    color: @button-font-color;

    /* Button -- Hover */ 
    &:hover,&.active {
        background: darken(@button-background-color, 10%);
    }

    /* Button -- Focus */
    &:focus {
        outline: none;
    }
}

/*----------------------------------------------
BUTTON
-----------------------------------------------*/
[class*="button"] {
    @button-background-color: #dfdfdf;
    @button-font-color: #3f3f3f;
    .button-background-color();

    /* Button -- Submit */
    &[class*="-submit"] {
        @button-background-color: #28B061;
        @button-font-color: #fff;
        .button-background-color();
    }
    /* Button -- Cancel */
    &[class*="-cancel"] {
        @button-background-color: #DD6859;
        @button-font-color: #fff;
        .button-background-color();
    }
    /* Button -- Edit */
    &[class*="-edit"] {
        @button-background-color: #E9A92E;
        @button-font-color: #fff;
        .button-background-color();
    }
    /* Button - View */
    &[class*="-view"] {
        @button-background-color: #3498DB;
        @button-font-color: #fff;
        .button-background-color();
    }
}

The code above is an example of how you can really begin to make the most of Dynamic Stylesheet Languages. The mixin allows the button and its add on elements to be created with minimal coding on your end. Additionally we have buttons which are utilizing Dry CSS and making better use of the LESS language. Now if we need to add any other parameters to our button we can build them into the mixin. How we use variables in this circumstance is also a great example of proper usage of these options within the constraints of LESS.

LESS and SASS are incredibly valuable tools that developers and designers should use whenever they can. Learning the proper use cases for the options each of these languages provides should not just make you faster. If that is all you set out to achieve then you will ultimately end up with inefficient, bloated CSS. The real goal is to write cleaner, more efficient code that you can manipulate with much less effort than basic CSS allows. Taking the extra time to understand how those practices can make your code better in the long run will lead to a much faster development cycle, and immensely more maintainable CSS.