As you might know I’m a big fan of the BEM Syntax. If you haven’t heard of it, it’s basically a way to name your CSS classes in a way that makes sense and gives everybody involved with writing CSS for the site some knowledge of the structure. It really helps to write modular CSS and makes it easy to understand the code even if you get into a project later on.

BEM stands for Block Element Modifier. Here is an example to get you started:

.nav {
    // This is the BLOCK
    margin-bottom: 20px;
}

.nav__item {
    // This is the ELEMENT
    color: #000;
}

.nav__item--active {
    // this is the MODIFIER
    color: #1193e5;
}

Some people don’t like how the notation looks, but I assure you it works really well and even some people I first had to convince are totally stoked now.
Now let’s look at Sass 3.3 and what it has to offer.

With Sass you can use & to reference the selector which is already in place if you want to nest code. Just like this:

.nav {
    margin-bottom: 20px;

    & a {
        color: #000;
    }
}

This compiles to the following CSS:

.nav {
    margin-bottom: 20px;
}

.nav a {
    color: #000;
}

That’s pretty nice and straightforward and helps a lot in authoring CSS. With Sass 3.3 it gets even better if you are a BEM guy or gal. Now you can write our first example like this and get the exact same CSS output only that your Sass looks cleaner and you have less to write:

.nav {
    // This is the BLOCK
    margin-bottom: 20px;

    &__item {
        // This is the ELEMENT
        color: #000;
       
        &--active {
            // this is the MODIFIER
            color: #1193e5;
        }
    }
}

The CSS output looks as follows:

.nav {
    margin-bottom: 20px;
}
.nav__item {
    color: #000;
}
.nav__item--active {
    color: #1193e5;
}

I haven’t used that in production myself yet, but I will as soon as possible because I think it’s great. But I can imagine that if one would nest to deep it can get a little confusing. But the good thing is, just because you use it in one place doesn’t mean you have to use it every time. Nevertheless, make sure you Sass follows some kind of style guide.

Now if you ask yourself if you have Sass 3.3 installed you can check this by typing

$ sass -v

into you console of choice. If you are not on 3.3 you can update with

$ sudo gem install sass

After installing check if everything went well with

$ sass -v

As of writing this post Sass is at Version 3.3.4 (Maptastic Maple).

If you have any questions or suggestions, feel free to send me a tweet at @_martinwolf or write an email at martin@visuellegedanken.de

Hope this article helps some of you. Have a nice day!

Although I’m not the biggest fan of Icon Fonts and am having a closer look at svg at the moment, I used Icon Fonts a lot in the past. Mostly custom ones created by a Designer for me. At superReal we created a pretty nice Sass Mixin which helps using icons across your project in the same way and having an overview over all your icons in one place.

Every icon in an Icon Font is basically a character of the font. In our example writing a t with the Icon Font as the font-family will result in a twitter icon. But because icons are just graphics that would leave screen readers and search engines clueless because t doesn’t mean anything to them. So you should also provide a text version of every icon which can be indexed by search engines and used by screen readers. So to accomplish that I use pseudo elements with the content property to display the icons and hide the standard text with CSS.
The HTML looks like follows:

<a class="twitter-icon" href="http://twitter.com/_martinwolf">
    <span>Twitter</span>
</a>

With CSS we can than hide the span and only show the icon.
Our Mixin has three options. The first one is the $type and is the most important one and is mandatory because it defines which Icon is used from the if statement below. The second one is the pseudo element which by default is :before and the third is the display option which by default is block. We also define the font size (in the case of an icon font the size of the icon) and the line height in the Mixin for each icon individually within the if statement.
At last we hide the span element.

@mixin icon($type, $pseudo: before, $display: block) {
    &:#{$pseudo} {
        color: inherit;
        display: $display;
        font-family: 'Icons';
        -webkit-font-smoothing: antialiased;

        @if $type == burger {
            content: 'b';
            font-size: 70px;
            line-height: 37px;
        } @else if $type == facebook {
            content: 'f';
            font-size: 24px;
            line-height: 24px;
        } @else if $type == twitter {
            content: 't';
            font-size: 24px;
            line-height: 24px;
        } @else if $type == youtube {
            content: 'y';
            font-size: 24px;
            line-height: 24px;
        }
    }

    span {
        display: none;
    }
}

With this Mixin in place we can just call it and create our Twitter icon like that:

.twitter-icon {
    @include icon(twitter);
}

Be default the before pseudo element and display block is used. If we would want to change that we can do it like this:

.twitter-icon {
    @include icon(twitter, after, inline-block);
    margin-left: 10px;
}

This would result in the following CSS code:

.twitter-icon {
    margin-left: 10px;
}

.twitter-icon:after {
    color: inherit;
    display: inline-block;
    font-family: 'Icons';
    -webkit-font-smoothing: antialiased;
    content: 't';
    font-size: 24px;
    line-height: 24px;
}

.twitter-icon span {
    display: none;
}

If you want to use Entypo for example, a very popular Icon Font, you have to watch out for a little thing. Entypo and a lot of other Icon Fonts don’t give you a simple text for the content property, they instead give you a Unicode. But you can still use this Mixin you just have to escape the code it.

This is what you get from Entypo:

And this is how you need to write your SCSS Mixin it to make it work:

content: '\1F50D';

I hope this helps you using Icon Fonts in your projects and makes your life a little bit easier.

Chris Coyier:

„Which CSS preprocessor language should I choose?“ is a hot topic lately. I’ve been asked in person several times and an online debate has been popping up every few days it seems. It’s nice that the conversation has largely turned from whether or not preprocessing is a good idea to which one language is best. Let’s do this thing.

Great piece by Chris Coyier. I started out and am currently using LESS, but in the last few weeks I suspected that SASS might be better in some ways. Chris confirms my hunch. So while I’m currently happy with LESS I think I’ll try switching to SASS. Although it’ll be some work to convert my LESS files, it seems to be the better alternative in the long run. I’ll keep you informed how it goes.