//TNG The Nitty Gritty

The low down on web technology

Decouple Your CSS From HTML With Reusable Modules

by Hans Christian Reinl

CSS Sass

Sass 3.2 has a wonderful method to define reusable modules called placeholders which enable us to decouple CSS from HTML while using unambiguous, semantic class names.

Oh and by the way… We've got a raffle to give a way a book. See more below.

A few weeks ago Ian Storm Taylor had a great article on how to find the best way to CSS using Object Oriented CSS and the CSS preprocessor Sass.

The OOCSS view of thing is that you define modules to work with and in order to change these modules - to build variants of them - you apply classes to an HTML element that change its styles accordingly.

![Bootstrap's Buttons](/content/01-home/002-decouple-css/bootstrap-buttons.png)
Differently styled buttons based on the OOCSS-technique in Bootstrap.

For instance here is an easy example of a button that changes its appearance when applying classes on it.

<button class="btn" type="button">Button</button>

<button class="btn btn-large" type="button">
    Large Button
</button>

<button class="btn btn-large btn-primary" type="button">
    Large Primary Button
</button>

Does this seem familiar to you? Well actualy this example is from Bootstrap. Bootstrap uses the approach of OOCSS to define modules and extends styles to define variants of these modules.

Since I am not a huge fan of abbreviations because of the confusion it may cost when working in a team let us assume btn is named button for further examples.

To me it seams like Bootstrap made the approach of modular CSS well known throughout developers that were not sure on how to design naming patterns for their HTML elements' classes.

The Concept of Modules

Modules are also known in other approaches that are kind of related to the Object Oriented CSS idea. For example in SMACSS modularizing your CSS plays a big role. SMACSS is a concept of designing consistent CSS to maintain flexibility throughout projects and within a team.

Please read the section on modules in SMACSS for a better understanding of how to build modules effectively.

Furthermore Nicolas Gallagher has an approach on how he defines class names and some more naming conventions which are somewhat related to the BEM approach developed by Yandex. These conventions help you to develop your own naming style for your modules.

To come back to Ian Sorm Taylor's article let us look at the way he provides to define class names on HTML elements more semanically while decoupleing HTML from CSS.

First off we want to look at an example of how to define the above buttons using OOSass as Ian describes it. Your HTML would look something like this:

<button class="button" type="button">Button</button>
<button class="button-large" type="button">Large Button</button>
<button class="button-large-primary" type="button">Large Primary Button</button>

The styles for these buttons can be defined as follows in Sass:

.button {
    // Styles for a button
}

.button-large {
    @extend .button;
    // More styles for large buttons
}

.button-large-primary {
    @extend .button-large;
    // More styles for a large primary button
}

Writing Sass this way ensures that we do not need to touch the HTML when we want to change the appearance of a large primary button for example. You can do it in styles only - decoupled.

In a lot of cases you want to change your large primary button to a normal large button which would need a class name change in your HTML. We don't want to do this. We do not like to change classes in our HTML as this might require a change within a part of the app of which we are not necessarily the boss of. Styling is our domain!

Those classes sprinkled all over your HTML are going to change, and that’s not gonna be fun.

OOCSS + Sass = The best way to CSS, Ian Storm Taylor

This is the major reason why you should keep your CSS names away from the things it intends to do. A large primary may become a normal primary button or a button may become a primary large button. You cannot be sure about what the intend of the element might be – except the sematical meaning of the element on the page.

Creating semanic class names decouples the CSS from your HTML. Semanic class names do not need to change just because the styling changes since the job of an element remains as is.

This is exactly the point Ian tries to make with his approach to OOSass. He gives examples of modules that you can define withouth a meaning, semanic-less, and reuse them when it is appropriate.

Building a module

So let's go on and build a module for the button we just created. Modules are especially useful for reuse. You can define modules once and use them on multiple websites with different design but the same intention.

In Sass 3.2 some interesting features landed. One of them are placeholders that work exactly like any other rule you define in Sass with the exeption that they are not actually printed within the compiled CSS when you don't use them. Generally you prefix placeholders with % followed by the placeholder's name. You can then apply them by using @extend.

So with this knowledge in mind let us define a button module that we can use whenever appropriate by sticking to the idea that Ian described.

![The module's code](/content/01-home/002-decouple-css/the-module.png)
This is how the code of our module looks in CSS including the call in `.download-whitepaper`.

We define some styles for a default button:

%button {
    background: #111;
    color: #fff;
    border: 0;
    padding: 0.5em 1em;
}

A large button basically has the same styling as this button but it needs to be a bit bigger:

%button-large {
    @extend %button;
    font-size: 1.3em;
}

Since we defined padding using em we do not need to do anything to increase the padding of the button.

Now when we are dealing with a primary Call-to-Action button all that should change compared to a "normal" button is the background color:

%button-primary {
    @extend %button;
    background: #27aae2;
}

For a primaty large button we just need to merge both the large style button and the primary style.

%button-primary-large {
    @extend %button-primary;
    @extend %button-large;
}

Let us use the button-module for a Call-To-Action button on a home page that asks the user to download a white-paper. It could be named (semantic class name) dowload-whitepaper. In Sass you are now able to apply the styles from your button modules while using a simple @extend call:

.download-whitepaper {
    @extend %button-primary-large;
}

See the full example module in this gist.

The CSS

Here is the output of the compiled CSS:

.download-whitepaper {
  background: #111;
  color: #fff;
  border: 0;
  padding: 0.5em 1em;
}

.download-whitepaper {
  font-size: 1.3em;
}

.download-whitepaper {
  background: #27aae2;
}

The output can be found in the aforementioned gist, too.

![The compiled buttons](/content/01-home/002-decouple-css/buttons.png)
This is how the different buttons look, labeld with the according module-parts.

This is not the best you can get out of CSS, since you could easily combine all rules into one without the repeated selecor. But there is more to it.

We just created a whole module with four different variations of a button that is easily reusable. We are not chained to a specific structure in HTML and we do not need to include a bunch of classes on an element just to change the appearance. We are not dependend on any other component of our app other than styles. We have decoupled our HTML fully from CSS.

And as mentioned before another advantage of Sass' placeholders is the fact that they are only compiled into CSS when they are effectivly used. So every module you don't need in your site is not in your CSS if you compile your styles correctly.

Conclusion

Decoupling components of your website or app are essential to be able to work independent from HTML and JavaScript.

With Sass 3.2's placeholders it is straightforward to define modules that you can reuse on every element by simply extending the module's variant to the element's class.

This can be especially handy for huge websites that reuse a lot of code in different variations and in teams where you build upon existing code.

Site note: This technique not new. There have been others noticing how easy you can decoulpe CSS using Sass. Harry Roberts for example uses this style of writing modules in his CSS framework inuit.css in the arrow-module. Also Joshua Johnson wrote about placeholders in Sass and their value when dealing with grids. And as pointed out Ian Storm Taylor wrote a great article on how to use placeholders in Sass.

![SMACSS by Jonathan Snook](/content/01-home/002-decouple-css/smacss-book.jpg)

Raffle

Since we want to encourage you to learn more about modularization and decoupling CSS we give away one of Jonathan Snook's SMACSS book. It is signed by Jonathan Snook himself.

All you need to do to take part in the raffle is to share this post via Twitter, Google+ or Facebook (mention and follow us to be save wink). If you want to you can also comment on this post and outline your opinion on the topic of decoupling CSS.

Please send an email to info@thenittygritty.co with the link to your share or mention us on Twitter. The raffle ends on Sunday 23:59h (all timezones, so you can still take part on monday afternoon if you are in New Zealand or something).

Update

The raffle is over and we want to thank everyone who participated. Congratulations to Alejandro García who won the book. If you didn't win the book you can still buy it from Jonathan's page.

Just to be sure: Any recourse to courts of law is excluded!
Image of SMACSS Book by courtesy of Jonathan Snook.

blog comments powered by Disqus