Janky: Of extremely poor or unreliable quality.

If you are writing just a few lines of CSS, it may not make a difference how you structure it. But as a project grows and the CSS becomes larger, the question of structuring CSS becomes more pertinent. There are a number of methodologies for writing better CSS. Some of the most popular ones are OOCSS, SMACSS and BEM.

In this article, we will explore these common methods for structuring CSS individually and talk about how they can be combined.

First let’s look at the basics:

In its basic form, CSS can be unstructured and difficult to manage. You can have an unordered mix of classes, id selectors and tag selectors without any particular naming or structuring conventions.

But once you begin to think about a way to structure your code, there are options:

OOCSS – Object-Oriented CSS

In its basic form, OOCSS is a way of applying Object Oriented Design concepts which we use in other programming languages like Java, Ruby or JavaScript to CSS development. In OOCSS, objects are individual html elements, groups of elements, and so on. There are two main principles in OOCSS which allow for greater modularity and re-usability:

  1. Separating structure from skin – means separating the structure and positioning styles from the presentational styles.

Note how .side-widget defines the structure and .recent-posts defines the appearance.

  1. Separating container from content – means to separate any given object from its container. Any object should be able to be placed in another container and still look and behave the same. This basically means to try to avoid using child selectors when possible.

A simple example would be:

You can get more details about this approach here (https://oocss.org/). But to really see the power of OOCSS let’s look at a really useful example which you can find and use in many places on the web.

The media object is an image to the left, with descriptive content to the right, like this Facebook story:

The content area on the right can contain any other objects. In this case, it contains text, but we could put lists, more text, but more importantly other media objects inside. If you think about it, you see this same pattern very often on the web.

Let’s take a look at the following code example:

  1. We clearfix both the wrapper element, media, and the inner content wrapper, body using the secret benefits of overflow. There are other ways we could have implemented the clearfix plus new formatting context.
  2. Then we float our image wrapper (generally a link) left.
  3. Finally, we set some margins and padding to keep everything lining up nicely.

There we go. It is a very simple object, but it is very powerful. We can eliminate a lot of lines of code using this repeating pattern.


SMACSS is a CSS framework by Jonathan Snook. On the SMACSS website (https://smacss.com/), he says it is more like a “style guide” than a rigid CSS framework. It focuses on five categories:

Base is used for defaults like html, body, a, a:hover. This includes your CSS resets and would often be in its own base CSS file or at the start of your main CSS.

Layout divides a page into sections with elements like header, footer, and article. Often developers show layout elements by prefixing the class with l-. Grids and lists would fall under this category.

Module is a reusable element on the page. SMACSS sees modules as the majority of your elements and doesn’t require you to prefix them but you could do so if you choose.

State is used for the variations possible, for each element (e.g. active, inactive, expanded, hidden). These are prefixed with is-, e.g. is-active, is-inactive, is-expanded, is-hidden or are via pseudo-classes such as :hover and :focus or media queries.

Theme is similar to state but defines how modules and layouts will look. It is more applicable for larger sites with shared elements that look different throughout. You would add theme variations on a per page or per section basis.

Child elements in SMACSS have the parent item prefixed with a dash. e.g. menu and menu-item.

SMACSS states that it’s all up to the choice of the developer. SMACSS just provides basic guidelines. Use your own naming conventions for each of the categories and arrange them in your preferred way, as long as you document your approach so that other developers can follow along.


BEM stands for Block Element Modifier and originated at Yandex. It provides a way to arrange your CSS classes into modules. There are a few ways to implement it and we will look at one of them:

A Block represents an object on your website. For example:

  • a person
  • a login form
  • a menu

An Element is a component within the block that performs a particular function. It usually only make sense in the context of its block. For example:

  • a hand
  • a login button
  • a menu item

A Modifier is how we represent different types of block. For example:

  • a tall/short person
  • a limited login form
  • a menu modified to look differently for some reason

In the example of our menu, the class names could look like this:

Bringing it all together:

There are a number ways to structure your CSS in a logical and modular way. All three described above are good choices and will make your code more efficient. The one which feels more intuitive to you would be the best way to start. But once you get better, it might be a good idea to familiarize yourself with all three methods.

There are people who use BEM and SMACSS. Ones who combine OOCSS and BEM and ones who combine all three. As you remember the Modules section in the SMACSS is very open-ended and so often is a place where developers use structuring like BEM or OOCSS. OOCSS is good, by itself but can be combined with BEM for bringing more maintainability to the naming of the objects / modules. Most of the time decisions of what to use on which project depend on the type of project you are developing. For example, if you are working on a large team with many developers of different skill levels, you might be better off using BEM as it provides a very structured approach and module naming conventions. The trade-off is that the actual class names end up being longer and are not always clear. So if you are developing a project by yourself, you may not want to use BEM and that would be the better choice for that particular project.

At the end of the day, all these tools are meant to make code more modular, reusable, maintainable and easier to collaborate with others, and using any one of them is better than writing unstructured code.

The following two tabs change content below.

Yevgeniy Gorodetskiy

Independent Author and Coder.

Latest posts by Yevgeniy Gorodetskiy (see all)