A Look at Some CSS Methodologies

CSS is notoriously difficult to manage in large, complex, rapidly-iterated systems.

One reason is CSS lacks a built-in scoping mechanism. Everything in CSS is global. That means any change you make has the potential to cascade and alter the presentation of unrelated bits of the UI.

Extended CSS languages, a.k.a. CSS preprocessors, such as Sass, Less and Stylus make things a little easier by offering up features that make writing CSS easier. But even these extended CSS languages, in my opinion, don’t truly fix the scalability issue.

Until CSS gets its own native scoping mechanism, we need to devise our own system for locking down styles to specific sections of an HTML document.

CSS methodologies are the solution.

In this article, we will take a look at these CSS methodologies:

Full disclosure: I’m the creator of Systematic CSS.

CSS methodologies are formal, documented systems for authoring CSS in a way that allows us to develop, maintain and scale the front-end as a set of small, isolated modules. Rather than as one massive lump of indivisible code.

Adopting a CSS methodology — even if it’s one that you create yourself — will make it easier for you to design and iterate on your web design projects, regardless of scale and complexity.

Related: CSS Development at Large-Scale Websites

Each CSS methodology offers a slightly different set of solutions to the CSS scalability/maintainability problem. A CSS methodology will often define guidelines for:

There is no "best" CSS methodology. Different approaches work better for different individuals/teams/projects.

Hopefully, looking at a few existing CSS methodologies will help you discover one that fits your needs. Or it might inspire you to create your own custom CSS-authoring guidelines.

Object-Oriented CSS (OOCSS)

CSS methodology: Object-Oriented CSS (OOCSS)

Nicole Sullivan’s Object-Oriented CSS, or OOCSS for short, was launched in 2009.

It was really the first CSS methodology to become widely adopted. It’s still hugely influential today.

OOCSS advocates the separation of structure from skin. The methodology makes a clear distinction between content and its containers.

In OOCSS, style rules are written exclusively using CSS class selectors.

OOCSS Example

For example, the style of your button elements might be set via two classes that you have given the class of:


.button {
  box-sizing: border-box;
  height: 50px;
  width: 100%;
.grey-btn {
  background: #EEE;
  border: 1px solid #DDD;
  box-shadow: rgba(0, 0, 0, 0.5) 1px 1px 3px;
  color: #555;


<button class="button grey-btn">

One goal of the OOCSS methodology is to reduce duplication of the same properties throughout your various style rules. In other words, OOCSS can help us maintain DRY stylesheets. The methodology attempts to achieve this goal by using lots of small, modular, specialist CSS classes.

Very few style properties are applied via type selectors (e.g. h1, div and body).


The use of descendant selectors is discouraged. For example:


/* Descendant selectors are discouraged in OOCSS */
.wrapper .blog-post .button {

This way, the presentation of your HTML elements is never dependent upon them being used in a specific context or DOM structure.

The great thing about the OOCSS methodology is it urges authors to make the most of CSS’s cascading behavior, rather than trying to lock it up with high-specificity selectors.

Related: How CSS Specificity Works

Authors are encouraged, whenever possible, to reuse existing style rules instead of creating new ones. We are also encouraged to extend style rules by specifying additional CSS properties with new classes, rather than modifying or overwriting existing CSS properties.


Let us say we want to give the first list item of an unordered list element a different color. This is one way to do it:


<!-- Counter-example -->
<ul class="to-do">
  <li>Combine my CSS files</li>
  <li>Run CSS Lint</li>
  <li>Minify my stylesheet</li>


/* Counter-example */
.to-do {
  color: #FFF;
  background-color: #000;
.to-do li:first-child {
  color: #FF0000;

OOCSS Example

To make our CSS more modular and flexible, and to avoid descendant selectors, the above counter-example could be rewritten in this manner:


<!-- OOCSS -->
<ul class="to-do">
  <li class="first-to-do-item">Combine my CSS files</li>
  <li>Run CSS Lint</li>
  <li>Minify my stylesheet</li>


/* OOCSS */
.to-do {
  color: #FFF;
  background-color: #000;
.first-to-do-item {
  color: #FF0000;

The main downside of OOCSS is that you can end up with an awful lot of classes. Which can be difficult to maintain and manage.

And, in my opinion, the concept of object-oriented programming — which is where OOCSS takes inspiration from — does not fit comfortably with CSS.

But that’s not to say the principles of OOCSS are invalid. On the contrary, OOCSS is a commonsense CSS methodology that brings back sanity to large-scale CSS development.

Block, Element, Modifier (BEM)

Block, Element, Modifier (BEM)

Block, Element, Modifier — more commonly called BEM — is a CSS class-naming system devised by the dev team at Yandex (the Google of Russia).

The idea behind BEM is to differentiate CSS classes that fulfill different roles. This is done by naming CSS classes in a way that indicates their role.

BEM complements OOCSS because OOCSS doesn’t impose any particular class-naming convention.

In BEM terminology, a block is an independent, modular UI component. A block may be composed of multiple HTML elements, or even multiple blocks.  An example of a block might be your navigation menu or search form.

An element is a component of a block. An element serves a singular purpose. For example, if you have a navigation menu block, then elements of it might be your navigation menu’s links, which in turn might be in the form of list items (li elements) and links (a elements).

A modifier is a CSS class that changes the default presentation of a block or element.

This is the BEM class-naming syntax:


Consider the following example, the markup for a login form:


  <label>Username <input type="text" name="username" /></label>
  <label>Password <input type="password" name="password" /></label>
  <button>Sign in</button>

BEM Example

Here’s the markup above with BEM classes applied:


<form class="loginform loginform--errors">
  <label class="loginform__username loginform__username--error">
    Username <input type="text" name="username" />
  <label class="loginform__password">
    Password <input type="password" name="password" />
  <button class="loginform__btn loginform__btn--inactive">
    Sign in

The .loginform class is the block.

The .loginform block is composed of three elements:

Element Purpose
loginform__username Take in the username
loginform__password Take in the password
loginform__btn Allow the user to submit the web form

The three modifiers are:

Modifier Description
.loginform__username--error When there’s an error, the element’s visual properties are modified so that it indicates to the user there was an error.
.loginform__btn--inactive The element’s visual properties are modified so that it has an inactive appearance.
.loginform--errors This modifier visually presents the login form in a manner indicating that it contains errors.

The BEM naming convention helps CSS authors comply with the OOCSS principle of using a flat selector hierarchy composed of equally-specific class selectors. It also helps OOCSS authors avoid deep descendant selectors.


So instead of the following style rule, which uses three CSS class selectors…


.loginform .username .error {

BEM Example

…you can just use a single class selector:


.loginform__username--error {

BEM is a very robust class-naming convention.

It successfully distinguishes the different concerns that classes are used for. And it’s easy to see in the markup which classes are related to one another.

A couple of subjective criticisms against BEM are:

Personally, I don’t think those are particularly strong criticisms. However, it would be nice to have a class-naming convention that is as robust as BEM, while also being a little tidier and more intuitive.

Scalable and Modular Architecture for CSS (SMACSS)

Scalable and Modular Architecture for CSS (SMACSS)

Jonathan Snook published his book on Scalable and Modular Architecture for CSS in 2011. Abbreviated as SMACSS. Pronounced as "smacks".

A key idea in this CSS methodology is how we categorize our CSS style rules.

Snook came up with five categories:

Category Description

Style rules that sets the default CSS properties of individual HTML elements. These are typically CSS type selectors.


h1 {
 font-size: 32px;
div {
  margin: 0 auto;
a {
  color: blue;

Style rules that are related to the structural layout of web pages. Containers, the grid, etc. They are prefixed with layout- or l-.


.layout-sidebar {
  width: 320px;
.l-comments {
  width: 640px;

Modular, reusable components.


.call-to-action-button {
  text-transform: uppercase;
  color: #FFF200;
.search-form {
  display: inline-block;
  background-color: E1E1E1;

Style rules that specify the current state of something in the interface.


.is-hidden {
  display: none;
.is-highlighted {
  color: #FF0000;
  background-color: #F4F0BB;
  border: 1px solid #CBBD15;


Themes Are style rules that affect layout and modules, triggered by user preferences/actions/viewing contexts.

SMACSS offers a simpler naming convention than BEM. There are no names for base styles because only type selectors (h1, p, a, etc.) are used for those. Modules are given their own unique class names. Sub-components and variations are prefixed with the name of their parent module.

SMACSS Example

Let’s say our layout is called .l-footer. We have a search form module inside it. The search form has already been submitted at least once by the user. This might be our markup:


<section class="l-footer">
  <form class="search is-submitted">
    <input type="search" />
    <input type="button" value="Search">

SMACSS discourages the use of descendant selectors. Jonathan Snook explains this by introducing a concept he calls depth of applicability. This concept is all about limiting the impact that CSS has on HTML markup by using classes to very precisely target elements you want to style.



Nicolas Gallagher’s SUIT CSS introduced in 2014, is interesting because it combines a BEM-like class-naming system with a CSS preprocessor. So SUIT CSS provides us with extended CSS syntax a la Sass, Less or Stylus.

SUIT CSS classes come in five formats:

This class-naming convention highlights the division between:

SUIT CSS Example

Here’s how this CSS methodology might get applied to a login form:


<form class="LoginForm LoginForm--errors">
  <label class="LoginForm-username is-required">
    Username <input type="text" name="username" />
  <label class="LoginForm-password">
    Password <input type="password" name="password" />
  <button class="LoginForm-button is-inactive">Sign in</button>

Systematic CSS

Systematic CSS

Systematic CSS is a new CSS methodology which I developed and launched recently.

Systematic CSS is based on a CSS-authoring system that I have fine-tuned over several years while working for various tech startups. Systematic CSS is how I personally compose web designs.

Systematic CSS shares many of the principles and ideas you can find in OOCSS, BEM, SMACSS, SUIT CSS, and other CSS methodologies.

Systematic CSS is meant to be a simpler alterative to existing CSS methodologies: There are fewer naming-conventions to remember, and the class-naming convention is intended to be more intuitive.

In the Systematic CSS methodology, the process of developing a new web design is broken up into four phases:

  1. Layout
  2. Elements
  3. Widgets
  4. Modifiers

Systematic CSS Example


First, an empty wireframe-like layout is created from a series of sectioning elements such as section and div:

<div class="CONTAINER">
  <header class="BANNER"></header>
  <nav class="NAVIGATION_PRIMARY"></nav>
  <nav class="NAVIGATION_SECONDARY"></nav>
  <main class="MAIN"></main>
  <aside class="ADVERTS"></aside>
  <footer class="FOOTER">
    <nav class="SITEMAP"></nav>
    <div class="LEGAL"></div>

Second, we establish the default presentation for HTML elements that will encapsulate content and render interactive controls. Examples include headings (h1, h2, h3), paragraphs (p), lists (ul and ol), tables, forms, and so forth.

Third, we identify recurring patterns of content in our designs. We bundle these recurring patterns up into independent modules of markup and styling (and scripting if needed).

These bundles of recurring content patterns are called widgets in the Systematic CSS methodology.

Systematic CSS Example

Here’s the markup for two widgets that render a navigation bar and search form:


<!-- navigation bar -->
<div class="NavBar">
    <li><a href="./">Home</a></li>
    <li><a href="about.html">About</a></li>
    <li><a href="learn/">Learn</a></li>
    <li><a href="extend/">Extend</a></li>
    <li><a href="share/">Share</a></li>
<!-- search form -->
<div class="SearchBox">
  <form action="search.html" method="get">
    <label for="input-search">Search</label>
    <input name="q" type="search" id="input-search" />
    <button type="submit">Search</button>

Content — in the form of widgets and naked HTML elements — is then placed within the layout.

Finally, modifier classes are added to vary the default presentation of things.

Systematic CSS Example

In the following example the navbar-primary modifier varies the default presentation of the NavBar widget, and the navbar-selected modifier targets the current selection:


<div class="NavBar navbar-primary">
    <li><a href="./">Home</a></li>
    <li><a href="about.html" class="navbar-selected">About</a></li>
    <li><a href="learn/">Learn</a></li>
    <li><a href="extend/">Extend</a></li>
    <li><a href="share/">Share</a></li>

In Systematic CSS, each class either:

  1. Represents the name of a layout section
  2. Represents the namespace for a widget
  3. Modifies the default presentation of something

Classes must fall within one of the three distinct purposes above. A class must not combine/fuse together the purposes above.

The three types of classes adopt different naming conventions, to easily tell them apart.

Class Type Casing
Widget .CamelCase
Modifier .lower_case

What’s nice about this naming convention is the hierarchy of classes is represented by their letter-casing.

Layout classes, written using all-upper-case letters, scream out from the markup. Examples: .NAVIGATION, .SIDEBAR, .FOOTER.

The CamelCase letter-casing of widgets, which will always be nested within layout classes, are a little less prominent. Examples: .MainMenu, .ImageGrid, .BlogPost.

Modifier classes — which are arguably the least important classes since they merely modify things and are not critical to achieving a default presentation — are the least conspicuous of all, being written in all-lower-case letters. Examples: .is-highlighted, .has-errors, .hidden.

In Conclusion

All CSS methodologies tackle the scalability and maintainability problem in CSS by providing a class-based system for breaking up big web designs into lots of small, modular, discrete units. Each UI module can be reused over and over throughout a design, and even ported from one project to another if two projects share the same CSS methodology.

In the process, CSS methodologies do much more than fix the CSS scalability problem. They make it easier to develop and iterate a design. They make front-end code easier to read and understand, provide ready-made documentation, and make it easier for multiple people to collaborate on a design.

Adopting a CSS methodology can reduce the learning curve for new designers joining a project, and make for a smoother transition when a project is handed over to a new team.

And because CSS methodologies encourage reuse of existing code, they enforce consistency in visual designs and reduce page size and increase page rendering speed.

CSS methodologies have different class-naming conventions and they carve up web designs along slightly different lines. But the specifics of any particular methodology are less important than the general solutions they provide for modularizing front-end code and making CSS easier to scale.

You can take away the ideas and develop your own categories of classes and devise your own class-naming conventions that work best for you. That’s what I do. Systematic CSS is my starting point, but every project is different, and I always tweak and extend my CSS methodology to better fit the skill set and creative temperament of the team I’m working with.

Other CSS Methodologies

Related Content

Kieran Potts is a full-stack developer specializing in building bespoke websites, web apps and RESTful web APIs for Internet startups. Visit his website:

This was published on Jun 22, 2015


Sonia Marquette Jun 22 2015

I’ve meant to look into CSS methodologies for a while, thank you for making an easy to understand post that summarizes the major methodologies. I like your Systematic CSS methodology. I already something similar, but I guess I could push it farther by applying some of your ideas.

Jason Hamilton-Mascioli Jun 23 2015

A great read on CSS! …. OOCSS

Efraim Jun 23 2015

I’ve always considered BEM CSS ugly, but after seeing Systematic CSS I must say it’s not that bad.

    That’s what I thought the first :-)
    UPPER_CASE css/html code? Are you kidding? This is so 2001…

    Nonetheless very good comparison of css methodologies!

      Oğuz Çelikdemir Jun 26 2015

      Uppercase or lowercase what is the difference between them? Who will see the code layout? If you don’t like to see uppercase letters, it’s your problem. Who cares someone told us do not use the uppercase letters!

      The main difference between lowercase and UPPERCASE is the fact that uppercase has a worse reading experience.
      As a developer you’ll see (hopefully) your code all the time you’re working. Not only in the html source but also in your css/sass/less and template files.

      What’s your problem with my opinion by the way? And I didn’t told you to use/not use anything – I just said it looks ugly :P

I prefer CSS methodologies over preprocessors… I feel like you can be real lazy with preprocessors, but with an approach such as this, it forces you to really think about the project as a whole, before you start, and attach it in a very methodical order (see what I did there?). Systemic looks pretty good, I like the naming convention. It’s a bit cleaner than OOCSS which seems like a bit much.

    Jacob Gube Jun 23 2015

    Well said Stan! I don’t think I’ve read anything that summarizes the idea behind using CSS methodologies better than what you’ve just said:

    it forces you to really think about the project as a whole, before you start, and attach it in a very methodical order

    Interesting view about CSS methodology versus preprocessors. Quick question to everyone reading this: Do you feel CSS methodologies and preprocessors are mutually exclusive?

    Because, in my view, using a CSS preprocessor with a CSS methodology makes everything easier (development, scalability, maintainability, etc.). I personally use Less or Sass with a personal guideline which borrows concepts from SMACSS and formatting from Code Guide by @mdo. This current set-up of using proprocessors with a set of rules/best practices (methodology), plus Gulp (used to be Grunt) to automate the build process for distribution (concatenation, minification, combining of selectors, versioning, prefixing, linting, etc.) literally cuts down my dev time to about 20-30% of what it was before. I.e. front-end design projects I used to do in five days, I can now do in one-two days.

    But the lesson I learned about preprocessors (and any awesome developer tool) is moderation. When I first started with preprocessors, I wanted to use every feature. And that ended up to be a nightmare. Preprocessors have good parts and bad parts. By using just the good parts, it will help you write code faster and manage your stylesheets easier.

      In my opinion it’s not exclusive for sure. I’ve been using SASS and BEM for a while now and I wouldn’t go back.
      Limit use of a preprocessor and a good methodology and it really helps you..

Taposy Rabeya Jun 24 2015

How much amazing!! very professional and creative work. Great job, thanks for sharing your technique with us. Please keep it continue for help us.

Rommel Jun 24 2015

for some reason i don’t like the idea of having UPPERCASE on css, my approach is SMACSS/BEM combined

Rob Levin Jun 25 2015

I really liked the simple to follow breakdown, especially for BEM which always used to baffle me. While I agree with dislike of UPPER in css, it’s purely aesthetic choice, and I do think you’ve got a nice framework there. I employ my own personal flavor of smacss (thus oocss indirectly). I do see the benefit of BEM’s relating “sub elements” to their block, but have always felt the syntax is ugly and terse (hungarian css notation lol).

Leszek Pietrzak Jun 26 2015

There’s also AMCSS ( methodology that uses attributes instead of classes. I do love the clean markup that it provides.

Theodoros Ploumis Jun 29 2015

This is a good idea. But I have a question. What is the proposed way to organize sass/scss files into folders?

Niklas Postulart Jul 02 2015

I’m missing the rscss methodology in your post. I think that’s a thing for people who doesn’t like the BEM syntax, like me.

Freya Watson Jul 10 2015

This blog is really helpful. I got chance to learn a lot about CSS from it. Thank you and keep posting.

To further iltrulsate how OOCSS can be used, I’ll use something similar to what I did on my site’s recent redesign . After coding the inner header element on my site, I realized that the basic structural styles for the inside of the header could be reused on other elements on the page.

This comment section is closed. Please contact us if you have important new information about this post.