Marius Hauken is a designer for screens at Netlife Research, Bergen, Norway.

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.

How Skitch can help you become a better designer

When you are designing you get to a point where it suddenly says stop. You don’t know what to change or how to make it better. This is the moment I fire up Skitch and take a screenshot of what I’ve just made. I then start to annotate and draw on that. There it is. My magic trick. It might sound stupid. It might sound pointless. But the fact is that by doing this I take a step back from what I’ve done and evaluate it in a new way. Often I see things I’ve never seen before in the design. Sometimes it takes seconds to fill the canvas with notes. Other times it’s more a struggle to find anything. This is when you are getting close to something good, or when you probably need to take a break.

An example of the Skitch design technique

This might be a simple design-equivalent to Rubber duck debugging; to explain what you’ve done and your choices, and then hitting upon the solution in the process of explaining the problem. You’ve probably noticed it before when you’re talking to colleagues or writing a post on Basecamp about your design-choices. Suddenly you see your design in a different light and need to sketch out some new ideas. If you have a printer nearby printing it out and writing on that works the same way. Firing up Skitch and taking a screenshot facilitates that kind of thinking for me. Maybe you should give it a try as well?

A push from an astronaut

During my christmas vacation I read Chris Hadfields excellent book “An Astronaut’s Guide to Life on Earth ”, and he talked about an interesting term that he called minus one, zero and plus one.

Over the years, I’ve realized that in any new situation, whether it involves an elevator or a rocket ship, you will almost certainly be viewed in one of three ways. As a minus one: actively harmful, someone who creates problems. Or as a zero: your impact is neutral and doesn’t top the balance one way or the other. Or you’ll be seen as a plus one: someone who actively adds value. […] I think about how to aim to be a zero and to try to contribute in small ways without creating disruptions. Chris Hadfield

These terms stuck a bit with me, and i thought quite a lot about that during my vacation. How can I stretch to reach a plus one instead of a zero on the web? (I sure hope that I’m not a minus one). Well, you can’t be a plus one without contributing anything. I’ve been very grateful all the times I’ve been stuck and suddenly found the solution to my problem because someone bothered to post their solution to the web. Hopefully I can pay it forward by posting some of my solutions and thoughts, and this way contribute in small ways. One year after Chris Coyier sparked the idea I just needed a little push from an astronaut to start…