UX Design and Development course

Theme rules - the deep dive

In SMACSS, Theme Rules are pretty loosely defined and talked about as being rarely used. I feel that Theme Rules play a very important role as far as setting the look and feel of the application extending upon what was stated in the Base Rules.

What is important to consider throughout the development of a site is that the theme is not always ever-present. It slowly exposes itself as the application evolves. It is the role and the responsibility of the a good UI dev to realize what is happening and find ways to remove the overly-specific application of a theme and reduce these down to more common ways of application.

For example, as I am building Module Rules, there are design aspects that clearly make their way into the module I am creating. But it is when I get to my second and possibly third module I begin to see patterns.

An easy pattern to see is the application of color or borders. As I engineer a module, in the context of the module itself, I apply the default theme.

Theme building strictly in CSS

Typically, Theme Rules will reside at the tail end of my CSS allowing them to over-ride any default theme rules I have applied to a module. In context of the Theme Rules that I reference that module's class and then apply the border width, style and color.

In this scenario, I am not required to decorate the DOM with a Theme Modifier class.

.module {
  border: 1px solid black;    <~ default theme rule
  ...
}

/* Theme Rules */
.module {
  border: 5px dotted blue;    <~ theme rule over-ride
}

Theme building in the DOM (OOCSS model)

Theme Modifiers, on the other hand, are classes that are designed to apply a theme concept to a module via extension within the DOM. When writing Theme Modifiers like these, I will use the theme- prefix on the modifying class.

.module {
  border: 1px solid black;    <~ default theme rule
  ...
}

/* Theme Rules */
.theme-borders {
  border: 5px dotted blue;    <~ theme rule over-ride
}
<div class="module theme-border"></div>

What was gained in this scenario is that as the application evolves over time, aesthetics like these have a greater opportunity for change then say the whole module itself. So when that happens, having the ability to go to a single area of the CSS and make sweeping changes will save you an amazing amount of time and greatly reduce the possibility of error.