On smaller brochure sites, how you organize your styles isn’t usually a big concern. You get in there, write some CSS, or maybe even some SASS. You compile it all into a single stylesheet with SASS’s production settings, and then you aggregate it to get all the stylesheets from modules into a nice tidy package.

However, when it comes to larger, more complex projects, how you organize your code is the key to efficiency in at least these three ways: it affects how long it takes you to write code, how much of that code you’ll have to write and how much loading your browser will have to do. This becomes especially important when you’re working with teams of themers, and when high performance is essential.

This is also true for long-term projects with legacy code (read “How to Scale and Maintain Legacy CSS with Sass and SMACSS” — some nice SMACSS and BEM mixing in there).


There are plenty of methodologies out there aiming to reduce the CSS footprint, organize cooperation among programmers and maintain large CSS codebases. This is obvious in large projects like Twitter, Facebook and GitHub, but other projects often grow into some “Huge CSS file” state pretty quickly.

  • OOCSS — Separating container and content with CSS “objects”
  • SMACSS — Style-guide to write your CSS with five categories for CSS rules
  • SUITCSS — Structured class names and meaningful hyphens
  • Atomic — Breaking down styles into atomic, or indivisible, pieces

Why BEM over the others?

No matter what methodology you choose to use in your projects, you will benefit from the advantages of more structured CSS and UI. Some styles are less strict and more flexible, while others are easier to understand and adapt in a team.

The reason I choose BEM over other methodologies comes down to this: it is less confusing than the other methods (i.e. SMACSS) but still provides us the good architecture we want (i.e. OOCSS) and with a recognizable terminology. - Mark McDonnell, Maintainable CSS with BEM

Blocks, Elements and Modifiers


Standalone entity that is meaningful on its own.


header, container, menu, checkbox, input


A part of a block that has no standalone meaning and is semantically tied to its block.


menu item, list item, checkbox caption, header title


A flag on a block or element. Use them to change appearance or behavior.


disabled, highlighted, checked, fixed, size big, color yellow

GitHub with captions

Under the hood

Let’s look how one particular element on a page can be implemented in BEM. We will take button from GitHub:

GitHub buttons

We can have a normal button for usual cases, and two more states for different ones. Because we style blocks by class selectors with BEM, we can implement them using any tags we want (button, a or even div). The naming rules tell us to use block--modifier-value syntax.


<button class="button">
	Normal button
<button class="button button--state-success">
	Success button
<button class="button button--state-danger">
	Danger button


.button {
	display: inline-block;
	border-radius: 3px;
	padding: 7px 12px;
	border: 1px solid #D5D5D5;
	background-image: linear-gradient(#EEE, #DDD);
	font: 700 13px/18px Helvetica, arial;
.button--state-success {
	color: #FFF;
	background: #569E3D linear-gradient(#79D858, #569E3D) repeat-x;
	border-color: #4A993E;
.button--state-danger {
	color: #900;



Block styles are never dependent on other elements on a page, so you will never experience problems from cascading.

You also get the ability to transfer blocks from your finished projects to new ones.


Composing independent blocks in different ways, and reusing them intelligently, reduces the amount of CSS code that you will have to maintain.

With a set of style guidelines in place, you can build a library of blocks, making your CSS super effective.


BEM methodology gives your CSS code a solid structure that remains simple and easy to understand.

Further Reading