< Back to CSS and Sass notes

Architecture and Conventions

Different large-scale ways to organize CSS and Sass

SEM

SEM stands for Scalable, Extensible, Maintainable. It’s a high-level CSS philosophy meant to inform all CSS written in a repository.

BEM

BEM stands for Block, Element, Modifier. It’s a CSS naming convention that helps keep specificity low and classes easily identifiable.

<div class="o-layout">
  <header class="o-layout__item o-layout__header">
    ...
  </header>
  <main class="o-layout__item o-layout__main">
    ...
  </main>
  <aside class="o-layout__item o-layout__item--slim o-layout__sidebar">
    ...
  </aside>
  <footer class="o-layout__item o-layout__footer">
    ...
  </footer>
</div>
.o-layout { ... }
.o-layout__item { ... }
.o-layout__header { ... }
.o-layout__main { ... }
.o-layout__sidebar { ... }
.o-layout__footer { ... }

The CSS for each class is not nested, affected by parent selectors, or influencing any child selectors. At most you’d need to nest 1-2 levels on, for rare cases. Usually things can be kept at a single class level, keeping CSS specificity low.

ITCSS

ITCSS is Inverted Triangle CSS, and is a file architecture to better organize CSS files so it’s easier to scale and maintain. It works best with a preprocessor like Sass, but can be used without it.

ITCSS requires importing or referencing all your CSS files in the following order, based on the following categories:

Note that as you go down the reference list, CSS specificity gradually increases. This fits with the cascading nature of CSS, so specificity is easier to manage and there’s less leaking styles. Classes expected to override others, like Components overriding Objects, will override predictably and help make the CSS maintainable and extensible.

OOCSS

OOCSS is Object Oriented CSS, and is a methodology for structuring CSS components. It approaches components like lego blocks: each component is built out entirely separate from each other, then combined to make larger ones.

Buttons are a good example of this. Different button styles, such as colors, border radiuses, size, etc, should all only be changed directly on the button with modifier classes. This makes the component extensible, and it can easily be used into larger components, like forms and footers. Different versions of the component can be used anywhere, the styles won’t leak or be leaked into, so it can be reliably used and changed without something breaking.

This methodology means you should: