Scalable and Modular Architecture for CSS
SMACSS aims at categorising CSS rules to produce patterns. It is more a of a style guide than a rigid framework.
SMACSS is a style guide that aims to create a structure for stylesheet files. The main focus is on categorizing CSS rules to produce patterns that are easy to follow.
In other words, the main idea is to not mix code of several categories on a single file because it can be very complicated to find a simple line of code to change. The purpose of this categorization is to codify patterns, that results in less code, easier maintenance, and greater consistency in the user experience.
Introduction
Before anything else, it has to be pointed out that SMACSS is more vague as a concept than the other methodologies.
SMACSS is a series of rules for categorizing CSS rulesets in order to make the CSS codebase more organized, clean, scalable, and modular. Following the SMACSS methodology, we can separate our CSS rulesets into five categories:
- Base
- Layout
- Module
- State
- Theme
This breakdown boils down to five separate files:
- _base.scss
- _layout.scss
- _module.scss
- _state.scss
- _theme.scss
Base
Base are the default values. They are like the padding, margin, border, typography properties — like font-family, etc. — and other properties.
This values are used within the entire website and for all elements. In other words, the base contains reset styles and global styles.
Layout
Layout divides a page into sections with elements like header, footer, main page, etc. Layouts hold one or more modules together. Often layout elements are ID’s eg. #header, #footer or by prefixing the class with l-, eg. l-header, l-footer.
Modules
Modules are the most important aspect of SMACSS. They are the reusable, modular parts of our design like navbar, sidebar and some elements that are repeated in the site.
They are unaffected by other user interface modules or layouts. Other examples would be an accordion, a modal or dialog, or a carousel.
State
State are ways to describe how our modules or layouts will look when they are into a particular state (eg. active, inactive, expanded, hidden). These are prefixed with is-, eg. is-active, is-inactive, is-expanded, is-hidden.
Let’s see how all of it translate in to code, based on an example:
body { } /* base */
a:hover { } /* base with pseudo-class */
#header { } /* layout */
.l-grid #footer { } /* two layouts */
.btn { } /* a module */
.btn:hover { } /* a module with pseudo-class */
.btn-xl{ } /* a sub-module */
.btn-xl:hover { } /* a sub-module with pseudo-class */
.btn.is-active{ } /* a module with state */
.btn.is-active:hover { } /* a module with state */
.btn-xl.is-active{ } /* a sub-module with state class */
.btn-xl.is-active:hover { } /* a sub-module with state with pseudo-class */
SMACSS in Design
How does it translate to design work? Biggets impact on design work has the division of patterns of UI pieces — base, layout, modules and states. Meaning that in order to go with this methodology you should also divide your design in the above-mentioned way.
So in the end, it would neither impact the wording of your layers in UI design tools, nor design tokens you’d create, but actually influence the grouping method of your layers.
I’ll give you an example. Based on SMACSS naming convention divide your artboards into to (1) base, with all the global tokens. Then have all different (2) layouts with all their use cases. After that (3) modules with all (4) sub-modules and each of their (5) states.
This unique trait of SMACSS is inherently connected to the fact that it’s more vague as a concept, than the other methodologies like BEM and RSCSS.
Learn more
This is how SMACSS pretty much works. If you’d like to explore more technical matters, you can read all about them here.
Other systems
No one is always right
I use feedback to improve UI Crux Platform. If you noticed a mistake, please report it.
