Marius Hauken is a designer and partner at Stacc X, Bergen Norway.

Tired of minified files when you search through your project?

Are you also tired of having your minified versions of CSS and JavaScript showing up when you are searching through your project?

It turns out there is an easy way to fix this if your are using Atom. Go to Atom => Config and add this to your configuration-file:

ignoredNames: [

Are you using SublimeText? Go to Preferences => Settings – User and add this to your configuration-file:

"file_exclude_patterns": [

I have added *-ck.js because that’s the default output from CodeKit for minified files. I’ve also added all CSS files since I just want to search through my SCSS.

Todos in SCSS

You can write todos to yourself in your scss by adding this line where you need to remind yourself of something:

    @warn "Add breakpoint here";

This way you get a nice warning each time you compile, listing out all your warnings. You could also use @debug instead of @warn. The difference is basically that you can turn warnings off with the --quiet command-line option or the :quiet Sass option, and that the warnings look a bit different:

How warnings and debug-notifications look in CodeKit
This is how warnings and debug-notifications look in CodeKit

When to use svg attributes

Are you inlining your svg in HTML5? Just use<svg></svg> tags without attributes.

Are you linking the SVG as an image, background-image or importing it another way that causes the User Agent to use an XML parser? Then you need the xmlns attributes like so:

    <svg version="1.1" xmlns="" xmlns:xlink="">`

How to use modifiers on modifiers with BEM?

For the last few project I’ve had the pleasure of naming my SCSS-files with the BEM methodology. The upside is easier maintainable files and far more informative class-names.

The BEM syntax is very strict and the naming convention follows this pattern:

.block {}
.block__element {}
.block--modifier {}

If you haven’t used BEM or haven’t got your head around BEM yet I highly recommend this article by Harry Roberts.

Usually it’s rather easy to tell if you are making a block, an element or a modifier, but one problem I’ve had again and again is a modifier on a modifier. Take this example:

We have these two buttons called .button--primary and .button--secondary coded like this:

    <a href="#" class="button button--primary">Main attention</a>
    <a href="#" class="button button--secondary">Cancel</a>

..and looking like this:

How the buttons looks normally

This works great on the regular background, but as you can see we got a problem if we need to wrap the buttons in a red warning-box or similar. We still want the same look, but maybe not green on red?

How the buttons looks on a red background

A few solutions comes to mind:

  1. .button--secondary--inverted

    We could add a modifier to .button--secondary. This just overrides the values that we need to change and we still need to add .button--secondary to the button. This feels a bit wrong and is very tiresome to write out. The code is however very logic to read and builds nicely on the BEM syntax.

  2. .button--secondary-inverted

    We make a seperate modifier which is almost a duplicate of .button--secondary, just changing the colors that we need to change. This is also very nice to read, but feels very bloated since you are copying almost every style.

  3. .button--inverted

    We create a .button--inverted class that changes .button--primary and .button--secondary if they have the .button--inverted class. Ex:

    .button--inverted {
        &.button--primary {
            color: black;
            background-color: white;
        &.button--secondary {
            color: white;
            border-color: white;

    This solution is a bit inconsistent with the BEM naming since we are using nesting. However the HTML is very nice to read and easy to remember. It also means that we can easily toggle the .button--inverted class with javascript without having to worry about if this class later on is going to be a .button--primary or a .button--secondary – the invertion will still work.

  4. .box--notification .button--secondary

    We could also nest the styling and say if .button--secondary is inside .box--notification we always want it to be white. This is probably the most dirty way to do it, but why not when you never want a green button inside a red box? The downside here is reusability and the location of the code. The big upside of BEM is the structure and that we from the name know the location of every class. If we suddenly start to nest classes we miss control.

I’m still not sure what is the best solution here. For now I’ve landed on alternative 3 mainly because the simplicity and readability. I’m eager to hear your thoughts and ideas. Give me a word on twitter or on mail about your thoughts.

Smarter toggling for good design and great performance

This is a repost of a post I’ve written for our company-blog, iAllenkelhet.

Good design isn’t just how it looks, but also how it works. This is why code is an important part of our design process at Netlife Research. By coding we can control other important design aspects of our website like speed, animation and how the design “feels”. We can also test how the site behaves on different devices and browsers.


A much used effective design pattern is toggling. Toggling lets us hide parts of the content behind a button to make the content more easily scannable. The main problem with toggling is performance. Smaller devices have the most to gain from toggling, yet ironically, they also are the least capable of rendering it. We usually have two different methods for toggling of content:

  1. Using jQuery's slideToggle. This is usually the best solution. The content slides in gradually and pushes the elements beneath it down. jQuery basically increases the height of the expanding element multiple times each second. On a fast desktop computer it looks like a nice animation, but on smartphones and tablets it can often become choppy and sluggish.
  2. Turning a hide class on and off. We can achieve the same result by adding or removing a class with the display:none property. This works well on any device, but is very sudden. The element doesn’t expand: it’s either visible or hidden. This can at times feel confusing for the user, especially if you are expanding a lot of content.

Performance of transitions

Neither of these solutions are optimal in my opinion. Even though I’m not a developer, I understand that performance is an important part of the overall user experience. I therefore looked further into how we could have a toggle-solution that animates and works well on most mobile devices. With CSS3 we have the opportunity to animate and use transitions in CSS. We can use transitions to animate the height (or max-height) of the expanded element. But it would still perform badly since we don’t make use of the devices GPU (Graphic Processing Unit) for rendering the animation and moving the content underneath. The only CSS properties that invoke the GPU to make smooth animations on mobile are transform and opacity. The optimal solution would be to move the content away with the transform property. The problem with transform is that it just moves the content from it’s original position: it still takes up the same space as it did before, leaving us stuck with a big empty area. The same is true for all the GPU invoking techniques.

[quote]The more content the browser has to rewrite, the slower it renders. [/quote]

Rewriting the content

Another important aspect of making smooth animations is that the more content the browser has to rewrite, the slower it renders. To avoid affecting other elements it’s therefore recommended that animated elements are position:absolute; or position:fixed;. After trying out a variety of different approaches I ended up fading the content in or out via opacity, and clever use of positioning combined with display:none; when the animation is finished. We still manage to push all the content underneath the element down, but with only one rewrite compared to a regular slideToggle tens of times each second. This performs nicely on mobile where the content fades in, and because it’s under the fold you won’t notice that the content is getting pushed down.

Example showing how a regular slideToggle works compared to the cssToggle-plugin


I’ve made my approach available as a jQuery plugin called cssToggle. In short the plugin checks if the element it’s called on is display:none; or not, then shows or hides the element via CSS opacity. When the animation is finished it sets the element to display:none; or display:block; based on it’s previous state. cssToggle also takes multiple options like position, speed, easing and firing functions after the animation is finished. This way you can easily tailor it to suit your needs. The plugin is about 1kb minified, and gracefully degrades on browsers that don’t support animations and just hides or shows the content with no fading. Grab the plugin on gitHub.

PS: If you would like a regular slideToggle(); on devices that can handle it, you could also use the excellent tool Modernizr and replace all your slideToggles with cssToggle when you detect touch-devices. While you’re at it I would also enable fastclick on these elements, to get rid of the 300ms wait before a click is registered.