By Una Kravets

People love naming things. And developers love acronyms. And thus here we are, finding ourselves with all of these CSS naming conventions and methodologies: BEM, SMACSS, Point North, ITCSS, OOCSS, Title CSS, Idiomatic CSS, Atomic Design, SUIT CSS, Kickoff CSS, etc.

We often hear “Are you using OOCSS or BEM?” but these things are not mutually exclusive. In fact, most of the time, we’re taking concepts and ideas of the aforementioned ideologies, and mixing them up, customizing them to suit (no pun intended) our own needs.

So what have I been using these days? Well that would be Atomic OOBEMITSCSS. Yep. Atomic OOBEMITSCSS.

The first time I heard this ridiculous term was from a tweet via Dan Eden, who tweeted:

I’m sure he doesn’t even remember tweeting that joke, but the more I thought about it, the more I realized it wasn’t a joke, and it hasn’t left my mind since. OOBEMITSCSS is exactly we’ve adopted, too. That sounds crazy, but it makes sense when you break it down.

Atomic CSS

Let’s Start with Atomic Design. Atomic Design is a systems-thinking methodology solidified by Brad Frost. Upon further research in finding how it relates to styling, I came upon this article on Atomic Sass. While I’m not using the directory structure outlined there, I do use the concepts and ideas expressed by Brad’s Atomic Design methodology in design work and extend them onto my development work (via Sass modules and components).

The gist is basically to design and develop in terms of systems thinking — to create individual molecules or elements which, when combined and placed together, weave a web of modules, components, and eventually entire layout systems. (Officially, there are 5 components to this: atoms, molecules, organisms, templates, and pages) You can start to see this in the following example:

Take this example from my Pinterest board:


Here we see a card. This card is made up of a few atoms:

  • caption text
  • header text (pin type)
  • body text (caption)
  • callout text (message)
  • callout text (title)
  • callout image (mini board)
  • source icons
  • local icons
  • numeric treatment
  • main image
  • dividers

These are then pulled together in sets of molecules:

  • Image & Citation (main image + source icon + caption text)
  • Pin Metadata (pin type text + hr + body text + [local icon + numeric treatment] x2)
  • Callout (callout image + callout text (message) + callout text (title))

Those molecules then comprise an organism aka the card itself:

  • (Image & Citation) + (Pin Metadata) + divider + (Callout)

The home page of Pinterest is full of these organisms. They make up a big part of the homepage layout:

Pinterest homepage

These elements are reused and remixed in other places on the site:

Pin It Modal

In the above “pin view” modal (which we see by clicking the “Pin It “button), we see the same treatment as we do on the homepage without the callout on the bottom, and placed in a different context.

Clicking on the Image

This is the view from clicking the image itself. Notice how the same header treatment and on the *type* of pin and source icon follows us throughout both of these views on the site. Atomic design thinking allows us to create modular, consistent design systems.


BEM is the system I use to mark things up. BEM Stands for Block, Element, Modifier. This is especially useful on a huge team, like the one I am now working within at IBM. I wrote a post about it once, but other people have written better posts since (I can’t believe that was 2013!).

So let’s take a look back at our first example of the card:


How would we mark this up? Well we would separate the markup based on its atomic structure first. This means we would start at the most basic level, and extend from there. Let’s isolate a small section to examine its markup. (note: I am intentionally disregarding treatment for links and interaction here in this example, but the ideas for marking those up persist. Using atomic markup allows for easy reuse of script actions whenever building components. I.e. the action for clicking the heart will always change its styling, such as fill color, and increase the hearts-count)

<div class="card">
  <img src="..." alt="..." class="card__source-icon">
  <a href="" class="card__source-link"></a>

  <section class="card__metadata">
    <h2 class="metadata__pin-type"></h2>
    <p class="metadata__caption"></p>
    <span class="metadata__pins"></span>
    <span class="metadata__hearts"></span>


  <section class="card__callout">
    <img src="..." alt="..." class="callout__board-preview">
    <p class="callout__msg"></p>
    <a href="..." class="callout__board-title"></a>

These class names are semantic to the content presented, and are broken up by their atomic molecules. Those molecules become the blocks in BEM. We don’t have modifiers in the above example, but if we wanted to separate the metadata of hearts (i.e. if *only* the heart was clickable), for instance (normally I’d just use a pseudo-element for the icon), we could write it like this:

<div class="metadata__hearts">
  <a href="..." class="metadata__hearts--icon"></a>
  <p class="metadata__hearts--count"></p>

Some argue that this leads to long selectors (it does), but semantically it makes a ton of sense and really cleans up your markup by limiting the number of classes you use. And by limiting I mean, seriously, try to use only **one class per element** if you can. Frankly, I find BEM invaluable for use within teams and works really well in an object-oriented manner (read on friends!).


OOCSS stands for Object-Oriented CSS. From Nicole Sullivan’s OOCSS workshop:

Basically, a CSS “object” is a repeating visual pattern, that can be abstracted into an independent snippet of HTML, CSS, and possibly JavaScript. That object can then be reused throughout a site.

The examples Nicole shows in her workshop use multiple classes to achieve this format, which, at this point, may leave you thinking: “Wait. Doesn’t this contradict BEM?” Nope. It doesn’t have to. We have Sass to make things right :) So it’s less OOCSS and more OOSCSS!

I like to think of the way I write my Sass as Object-Oriented. If we think of the card as an “object” which pulls in various “classes” to comprise it, we can still keep everything nested nice and neat with the use of the almighty ampersand (if you’ve read any of my previous blog posts you’ll know how much I love the ampersand.

Example time! Let’s use the metadata section for this, as it provides a good example of hidden complexity:

<section class="card__metadata">
  <h2 class="metadata__pin-type"></h2>
  <p class="metadata__caption"></p>
  <span class="metadata__pins"></span>
  <span class="metadata__hearts"></span>

We’ll want to be thinking modularly and in the realm of object-oriented encapsulation. Icons are a great start:

%icon {
  content: '';
  display: block;

  &--pins {
    @extend %icon;
    background-image: url('../img/pins.svg');

  &--heart {
    @extend %icon;
    background-image: url('../img/heart.svg');

Woah. What’s going on here? Well A) like I said earlier, I overuse ampersands, so make sure you’re familiar with those. B) We’re creating an invisible (aka “placeholder selector“) in Sass. This means that none of this code is processed into CSS until we @extend it. All of our icons will have some shared properties (in this case, content: '' and display: block). Then we specify the background-image for each individual icon while *extending* the styled from its parent block. This can be done with a simple @each loop and icons can be organized within a map to make things cleaner. Nothing is being output here, but technically, this is what’s going on behind-the-scenes:

%icon--heart {
  content: ';
  display: block;

%icon--pins {
  background-image: url('../img/pins.svg');

%icon--heart {
  background-image: url('../img/heart.svg');

So continuing on, let’s see what the block looks like when written in a object-oriented Sassy way. Let’s just get a grounds for some typography that we’ll instantiate in a moment when building out our component:

%font-stack--body {
  // actual Pinterest font stack (!)
  font-family: 'Helvetica Neue','Helvetica','ヒラギノ角ゴ Pro W3','Hiragino Kaku Gothic Pro','メイリオ','Meiryo','MS Pゴシック',arial,sans-serif;

%font-stack--headers {
  @extend %font-stack--body;
  font-weight: 600; //headers are the same typeface as everything else but have a heavier weight

%type--base-body {
  @extend %font-stack--body; //extend the body stack

%type--base-h2 {
  @extend %font-stack--headers; //extend headers (which extend body stack and give them a heavier weight)
  font-size: 1.5em; //font-size adjustment

And now to the molecule! This is where it gets really delicious:

.metadata {
  &__pin-type {
    @extend %type--base-h2; //extend base header styling

  &__caption {
    @extend %type--base-body; //extending normal body copy

  &__hearts {

    &:hover {
      color: red; //unique hover color

    &:after {
      @extend %icon--heart; // extending heart icon on pseudo element

  &__pins {

    &:hover {
      color: green; //unique hover color

    &:after {
      @extend %icon--pins; // extending pins icon on pseudo element

What does that look like in CSS? Despite all of the nesting, we output one single class for everything!

.metadata__hearts:after {
  content: ';
  display: block;
.metadata__pins:after {
  background-image: url('../img/pins.svg');
.metadata__hearts:after {
  background-image: url('../img/heart.svg');
.metadata__caption {
  font-family: 'Helvetica Neue','Helvetica','ヒラギノ角ゴ Pro W3','Hiragino Kaku Gothic Pro','メイリオ','Meiryo','MS Pゴシック',arial,sans-serif;
.metadata__pin-type {
  font-weight: 600;
.metadata__pin-type {
  font-size: 1.5em;
.metadata__hearts:hover {
  color: red;
.metadata__pins:hover {
  color: green;



Okay, this is where we pull it all together. We’re almost at the finish line! So. Let’s talk ITCSS. First of all, what is ITCSS? Well IT (lol) is a methodology for how to author your stylesheets that answers the exigent question of of how the heck do I order my styles?

Here is an excellent visual, stolen directly from Harry Roberts’ blog post on the Specificity Graph (sorry, hope you don’t mind!)

In Essence:

This is what your specificity graph (probably) looks like:

Specificity Graph

This is what your specificity graph *should* look like:

Specificity Graph Ideal

The specificity graph is an analysis of your CSS code specificity. When using !important statement and overriding your code earlier-than-necessary, it creates these dramatic peaks, causing you to then need to override it again to override the too-specific override. Do you see why this is problematic? Not only is it confusing and non-semantic, but it also causes you to write less-performant code and produce larger stylesheets because of all of your overrides. Your stylesheet size can be represented as the area below the graph.

How, you ask? In the example above, we see that we supply the broadest styles first, and then we only apply specific styles when we need to, to the element or modifier. Otherwise, we extend from existing code, that is created earlier in the flow of the styles. It helps to organize your stylesheets modularly, and use the first few imports as helpers or variables that don’t output any CSS (like the placeholder selectors for icons and typography). I could (and have) written entire posts on this subject (and have even made a tool for authoring your stylesheet architecture, forcing you to plan a route before delving in).

So there you have it, Atomic OOBEMITSCSS.

  • M S i N Lund

    Those who can, invent new stuff.

    Those who cant, makes up new names for existing stuff.

    • Kristov PauhnoCu

      These “freelancers” (in fact, this people without a proper job) spend so much time “creating” useless tools.

      • Stuart Robson

        Hi Kristov, for some clarity… Una works for IBM, Dan Eden (mentioned in the post) works for Dropbox, SMACSS is from Jonathan Snook who’s recently gone back to freelancing from working for Shopify and BEM was created by Yandex, a Russian search engine. Hardly ‘freelancers’ in my opinion :)

      • Darío Santacruz

        However nobody is forcing anybody to learn something that might actually be useful.

  • M S i N Lund

    Those who can, invent new stuff.

    Those who cant, makes up new names for existing stuff.

  • Elliot Birch

    I’ve been using BEM for all of my current projects. It’s saved me multiple times in many different ways. And I’m one of those people with a “proper job”.

  • Brendan Patterson

    Great post, I (and the company I work for) have adopted BEM & ITCSS (with a few instances of SMACSS mostly for states (like .is-active)) – build time has decreased, bug fixing time has decreased and handovers between devs are now very easy.

  • Nicolas Hoffmann

    My personal micro-framework is using a variation of your method : SMOOATOCSSEMSY. :) (SMACSS, OOCSS, BEM, Daisy, atomic and sometimes even the FUCSS approach : what the FuCSS !)

    Anyway, it is good to read your post: just use everything that is good in each method, I really do like state classes, OOCSS principles, BEM notation for modules, etc.

  • Corey Bruyere

    I’ve never seen BEM block classes inherit their parents __element name, e.g.

    .card__metadata {}

    .metadata__caption {}

    wouldn’t it be shorter to just lose the .card__metadata and use .metadata ?

    Great reference article though.

    • David Gowrie

      That would be shorter, but your suggestion would not follow the BEM convention, which is to (among other things) make that parent-child (i.e. “block” and “block__element”) relationship explicit.

      To borrow an example from Harry Roberts (referenced in the article), take the following CSS selectors which are *intended* to be related but in fact are rather disconnected:
      .person {}
      .hand {}
      .female {}
      .female-hand {}
      .left-hand {}

      Expressing the same components using BEM, you make those intended relationships clear at a glance:
      .person {}
      .person__hand {}
      .person–female {}
      .person–female__hand {}
      .person__hand–left {}

      I found this article on an BEM-like approach very helpful:

      • James TW

        The most challenging part of BEM, for me, comes immediately after this step.

        For example, how would you semantically describe a female person’s left hand? Surely not .person–female__hand–left…

        What about a finger on a person’s hand? Do we drop .person and go with .hand__finger? How can we distinguish this from a monkey’s finger while keeping specificity low?

        Being restricted to 3 components max (block, element, modifier) causes me quite a headache sometimes.

        • David Ollerhead

          Totally agree, have never really been fully satisfied with any approaches to this issue. Even the limit of 3 seems a push, as it seems wrong to use the –modifier to just represent a grandchild, as opposed to truly modifying the state of the element.

          The typical response to think more abstract and break into smaller modules, isn’t always feasible.

  • dehuszar

    I’ve been a little frustrated with all the utility classes and visual-outcome labelling that gets rolled into a lot of these CSS design systems and frameworks. This seems like a nice middle ground.

    In my own work, I take a similar approach, but go about it in a slightly different way. I’m using LESS for one. For two, LESS allows multiple layers of extending, which if used poorly can lead to some bloat, but when approached from a component level (i.e. extending larger nested blocks and not extending lots of little pieces) it helps me make similar modular abstractions, keep specificity low, and mix-and-match different frameworks (like Bootstrap buttons and Pure’s grid). My outputted filesize rarely gets above 10k, depending on the project. …and that’s including the frameworks.

    For those interested:

  • Luca Rosaldi

    It’s interesting to see how the BEM nesting is implemented by Una.

    I believe that the main issue with BEM is nesting. I mean, if you nest infinitely you can easily end up with class names such card__metadata__pins__title, or something like that.

    So, Una dropped the card__ prefix after the first nesting, which was card__metadata, and then used only the metadata__ prefix for the nested items.

    This is perfectly fine, given that “metadata” is a molecule which in this case is contained inside the organism “card”. The only problem I see here is that “metadata”, or “callout”, or “image” are too weak and generic as class names, and could be easily used for more than one purpose.

    I don’t know about cache busting, but indeed I agree the most difficult thing in computer science is naming things.

    • dtinth

      To solve this nesting problem, I employ a simple rule: Don’t nest more than one level deep. This means .card__metadata is OK, but .card__metadata__pins is not.

      If an element needs more than one level of nesting, then most likely that element is too complex. It is advisable to refactor and decompose them into multiple elements.

      In addition, I use several other rules about styling and layouting to make elements more easily composable, which I described in an article I wrote several months ago: Towards a More Maintainable CSS.

      To prevent name clashes, I separate the CSS source code into many files. Each file may only contain the CSS definitions of the element of the same name. So, all selectors in metadata.scss must begin with .metadata.

      Anyway, I think the web is heading towards CSS Modules, which should solve these problem once and for all. An article The End of Global CSS gives a nice introduction to CSS Modules. It is already implemented in Webpack.

    • Brendan Patterson

      That stood out to me as being a little bit odd but I guess it comes down to how abstracted each ‘block’ is intended to be, I would have prefered ‘.card__metadata-caption’ over ‘metadata__caption’ or have ‘metadata__caption’ nested under ‘.card__metadata’. This concept is discussed here

  • davecranwell

    The most baffling thing about the OOBEMITSCSS discussion is that I can’t understand how anyone would meaningfully apply just one of these amusingly merged acronyms without also doing some of the others too. How would you structure a SCSS codebase using Atomic pattersn, BEM or OOCSS without also needing ITCSS? All these technologies are just facets of the same thing: well organised code. It would be a strange individual who truly understood BEM well enough to apply it properly and yet somehow didn’t do the rest too!

    Having said that you could choose BEM *over* OOCSS, not all these acronyms need applying all at once, but still. The principals of good code are acronym-agnostic. If you write truly maintainable code, you’ll find yourself applying little bits and pieces of each one of these disciplines without realising.

  • Joey Augustin

    Well done Una…taking a cue from each convention that suits your projects needs. Indeed the hard part about CSS these days is scoping and organization.

  • Bikas

    Everything seems OK but I can never get my head around BEM. First I use SCSS (still) to compile to css and my SCSS is modular like SMACSS.

    Now, in the module, I create something like this

    .card {

    .link-heart {
    .some-modifier {}
    .metadata-caption {
    .some-property {}

    It’s concise, understandable, readable even under too many nesting (although I never goo more than 4 level deep), and modular.

    Although I didn’t explicitly mentioned which is what, but card definitely is a block, inside are elements and they have modifiers. It’s very simple to understand from the code and at the same time if properly named (not dome here), it’s way too simple to get what CSS do from HTML as well.

    • dehuszar

      Yeah, this is much cleaner and my preference as well.

  • Karsten Buckstegge

    Generally I like your approach. But one thing seems dangerous to me and that is the heavy use of extend in your code.
    I always try to avoid it because it creates very hard to understand code. A good example is the code within the OOCSS part:
    If you change something in font-stack–body this will also change in font-stack–headers, type–base-h2 and everything that extends these classes and you have no indication at the font-stack–body class that will tell you what other classes this influences.
    On very small projects with few developers on them this might be maintainable but if you get a little bigger this can create huge confusion for everyone working with the css.
    It kind of goes in the direction of the pitfalls with classical inheritance in Javascript that Eric Elliott points out in his article on medium ( ).
    If you are not very careful (and being honest, very few developers are) with that, you end up with code where you never know what’s going to be influenced if you change a css rule.

  • Thierry Koblentz

    Since we’re talking about naming things: “Atomic CSS” ( and “Atomic Design” ( are 2 different things.

  • Kevin Mack

    I really enjoyed everything you wrote and I love the hilariously long fun name for this. These are all methodologies, approaches, and practices that I use in my UI development and I talk about the combination of all of these on a day-to-day basis; I will for sure use this article as a reference point for devs that are unfamiliar with these. Thanks for crushin’ this!

  • Jay

    What is the CSS that accompanies your first HTML example? Are the styles for `metadata__caption` defined in a descendant selector of `card__metadata`? Or are those styles independent of the DOM hierarchy?

  • David Kiv

    Brilliant article Una! Very informative – have been looking to move my css/sass onto the next level – this is a great place to start my research!

  • Josh Medeski

    I’m honored that you linked to my BEM article Una, thanks!

    The second I read the headline for this article it clicked. I never put it in perspective that I’m using all of these methodology together (but I am!).

Get the latest in Front-end, once a week, for free.