Long-standing CSS methodologies

Oct 03, 2019css

CSS methodologies (or naming conventions) are old and boring to talk about 😏. There are two reasons for that: CSS is so mature with established documentation about how to manage stylesheets, and people are moving to CSS-in-JS.

However this topic is extremely important and can’t be ignored even if you like it or not. CSS-in-JS is new and used by mostly startups and indie makers, but these CSS methodologies are still being used everywhere in enterprises.


Coming from how CSS works, the problem with CSS is that they rely on developers to manually maintain them with a high degree of accuracy to be effective. The language is simple and easy to learn, the hard part is how to write CSS in a maintainable and scalable way.

Sadly, most CSS stylesheets are sometimes developed without any structure or naming conventions. As web projects grow, managing CSS can quickly become challenging if you don’t put any forethought into how the code should be structured. Redundancy and poor performance are two main consequences.

Since the inception of CSS, the community tried to fix above problems of CSS language with many guidelines, standards, preprocessors and methodologies.

CSS methodologies are naming conventions used by developers to better manage CSS which lacks built-in scoping mechanism.

There are only two hard problems in Computer Science: cache invalidation and naming things — Phil Karlton

The industry darling BEM

BEM is a methodology, a naming system, and a suite of related tools. Created by the team at Yandex. Its name is an abbreviation of the key elements of the methodology — Block, Element and Modifier.

  • Block: Standalone entity that is meaningful on its own. (header, container, menu)
  • Element: A part of a block that has no standalone meaning and is semantically tied to its block. (menu item, list item, checkbox caption)
  • Modifier: A flag on a block or element to change appearance or behavior. (disabled, highlighted, enabled, checked)

BEM enforces following rules:

  • Elements are namespaced using the Block names and separated by __ (double underscores) whereas the Modifiers are separated by — (double hyphens).
  • You also shouldn’t use CSS tag or ID selectors when using BEM.
.form {
.form--theme-xmas {
.form--simple {
.form__input {
.form__submit {
.form__submit--disabled {
<form class="form form--theme-xmas form--simple">
  <input class="form__input" type="text" />
  <input class="form__submit form__submit--disabled" type="submit" />

BEM has been hugely adopted by industry over years because of following benefits:

  • BEM methodology gives your CSS code a solid structure that remains simple and easy to understand.
  • Because of its strict naming conventions, we won’t run into conflicts with other CSS names. Everyone who participates in the development of a website works with a single codebase and speaks the same language.
  • Everything is a class and nothing is nested, this makes CSS specificity very flat and low, it means you won’t end up fighting with yourself over specificity.

What BEM offers is to make class names longer, always make elements dependable from block title and declare all classes globally. It literally helps nothing and leads to sad consequences in project markups. You might be restrained from using BEM cuz of its drawbacks:

  • Prolonged and PHP-like name classes making any markup unreadable
  • Any class in BEM is global causes difficulties with modifiers inheritance
  • Implies markup only by blocks causes prohibiting of semantic usage

The rebellious maverick Atomic CSS

Atomic CSS is not opinionated; it simply defines a set of classes representing single-purpose styling units. It uses a tight library of class names which are often abbreviated and divorced from the content they affect.

Atomic CSS is the approach to CSS architecture that favors small, single-purpose classes with names based on visual function.

Atomic CSS is for developers who see the benefits of styling “outside of style sheets” — who want to write markup and styles in one place while benefiting from a Atomic architecture. It is a switch of priorities. You don’t maintain style sheets but components.

Atomic CSS is starting to gain ground:

  • Highly granular, highly reusable styles, instead of rules for every component
  • Greatly reduces specificity conflicts by using a system of low-specificity selectors
  • Allows for rapid HTML component development once the initial rules are defined
  • The lower specificity of classes also allows for easier overrides
<button class="b1 b--green bg-green white br-5 ma-10 f3 ttu fw-400 padding-10">
  Click Me!

Atomic CSS refers to an architectural philosophy, not any one particular library or framework, and encompasses both static (e.g. Tachyons) and programmatic (e.g. ACSS) approaches. For a clear definition and information on related terminology, read Let’s Define Exactly What Atomic CSS.


Object oriented CSS was proposed by web developer Nicole Sullivan in 2008. Her goal was to make dynamic CSS more manageable by applying the principles of object oriented design popularized by programming languages such as Java and Ruby.

Generally speaking, CSS is object-oriented when it considers classes that are reuseable and targetable to multiple page elements.

The purpose of OOCSS is to encourage code reuse and, ultimately, faster and more efficient stylesheets that are easier to add to and maintain. Two main principles of OOCSS are:

  • Separate structure and skin: This means to define repeating visual features (width, height, margins, paddings, etc) as separate skins (colors, fonts, shadows, gradients, etc) that you can mix-and-match with your various objects to achieve a large amount of visual variety without much code.
  • Separate container and content: This means rarely use location-dependent styles. An object should look the same no matter where you put it.
<a href="#" class="btn btn-small btn-salmon">Click me!</a>
<a href="#" class="btn border btn-medium btn-mint">Click me!</a>
<a href="#" class="btn border box-shadow btn-small btn-blue nice">Click me!</a>

Over time, the OOCSS technique can lead to hundreds of CSS classes with individual properties applied dozens of times in a given document. People do have problem with OOCSS due to the verbosity of HTML with too many classes, considered this to be non-semantic.


SMACSS stands for Scalable and Modular Architecture for CSS, is more like a style guide to document a consistent approach to site development when using CSS.

At the very core of SMACSS is categorization. By categorizing CSS rules, we begin to see patterns and can define better practices around each of these patterns. There are five types of categories:

  • Base: Exclusively single element selectors, attribute selectors, pseudo-class selectors, child selectors or sibling selectors.
  • Layout: Divide the page into sections
  • Modules: Reusable, modular parts of our design
  • State: Describe how a module or layout looks on screens
  • Theme: Describe how modules or layouts might look

It is recommended to enter the namespace for classes belonging to a certain group, and also to use a separate namespace for the classes used in JavaScript.

Other incompetent solutions

ITCSS — A sane, scalable, managed CSS architecture from CSS Wizardry

MCSS — Multilayer CSS organization methodology is a guideline to structure your CSS. This style of code writing suggests splitting styles into several parts, called layers like foundation, base, project and cosmetic.

AMCSS — Attribute Modules (AM) is a technique for using HTML attributes and their values rather than classes for styling elements.

FUN — stands for Flat hierarchy of selectors, Utility styles, Name-spaced components. This approach imposes quite a few requirements on the project and the code structure, it only establishes the preferred form of recording selectors and the way they are used in the markup.


The state of CSS methodologies is quite stable for years. While BEM is ahead of the pack here, Atomic CSS is also starting to gain ground with its completely new utility-class-driven philosophy. Other solutions are incomplete and fading away.

Simplicity is the ultimate sophistication.

In the end, we might never find the one true way to write CSS, but that’s not going to stop us from looking. we might end up with a complicated solution mixing multiple CSS frameworks, methodologies and preprocessors.

I switched to CSS-in-JS after many years using BEM and the experience has been more than satisfied, one main reason is that I can use the same styling technique in React Native.