BEM Methodology: A Step-by-Step Guide for Beginners

BEM Naming Convention Examples

BEM's naming convention follows a precise pattern: .block__element--modifier. Getting the naming right is where most teams either gain significant maintainability advantages or introduce the inconsistencies that erode BEM's value over time. The following reference covers the naming rules, common patterns, and the mistakes that appear most frequently in production codebases.

The Three BEM Entities

Block: A standalone, meaningful component. Named with a single hyphen to separate multi-word names.

.search-form

.nav-bar

.user-profile

.data-table

.alert-banner

Element: A part of a Block that has no standalone meaning. Connected to its Block with a double underscore (__).

.search-form__input

.search-form__button

.nav-bar__item

.user-profile__avatar

.data-table__header

Modifier: A flag on a Block or Element that changes its appearance, behavior, or state. Connected with a double hyphen (--).

.search-form--expanded

.search-form__button--disabled

.nav-bar__item--active

.user-profile--compact

.data-table__header--sortable

Naming Rules at a Glance

The "No Element of an Element" Rule

This is the rule that causes the most confusion. In BEM, you never chain elements: .block__element1__element2 is always incorrect, regardless of how deeply nested the HTML structure is.

Problem pattern:

/* WRONG: element of an element */

.card__header__title { }

.card__header__icon { }

.card__body__paragraph { }

Correct pattern:

/* RIGHT: all elements belong to the Block, not to each other */

.card__title { }

.card__icon { }

.card__paragraph { }

The CSS class name reflects the element's relationship to its Block, not its position in the HTML tree. A .card__title belongs to the .card Block regardless of whether it sits inside a <div class="card__header"> in the markup. If the .card__header container is later removed or restructured, the element names remain valid.

When nesting truly requires a new scope, create a new Block. If the header section of a card is complex enough to have its own elements and modifiers, it should be its own Block:

/* Separate Block for complex nested structures */

.card-header { }

.card-header__title { }

.card-header__icon { }

.card-header--collapsible { }

Boolean vs. Key-Value Modifiers

BEM supports two modifier patterns:

Boolean modifiers represent a simple on/off state:

.nav__item--active { }

.form-field--disabled { }

.modal--visible { }

Key-value modifiers represent a choice among options:

.btn--size-small { }

.btn--size-large { }

.btn--theme-primary { }

.btn--theme-secondary { }

.alert--severity-warning { }

.alert--severity-critical { }

Key-value modifiers are particularly useful for design systems where components have multiple configurable dimensions. A button might combine .btn--size-large with .btn--theme-primary, and both modifiers remain readable and non-conflicting.

Naming Convention Cheat Sheet

Block:            .block-name

Element:          .block-name__element-name

Block Modifier:   .block-name--modifier-name

Element Modifier: .block-name__element-name--modifier-name

Key-Value Mod:    .block-name--key-value

Real component mapped to this pattern:

.search-form                         /* Block */

.search-form__input                  /* Element */

.search-form__button                 /* Element */

.search-form__results                /* Element */

.search-form--expanded               /* Block Modifier (boolean) */

.search-form--theme-dark             /* Block Modifier (key-value) */

.search-form__input--focused         /* Element Modifier (boolean) */

.search-form__button--size-large     /* Element Modifier (key-value) */

BEM vs Other CSS Methodologies

BEM is not the only CSS methodology available to development teams. Understanding how it compares to alternatives helps organizations make informed architectural decisions, particularly for large-scale enterprise applications where CSS maintainability directly impacts development velocity and onboarding speed.

Methodology Comparison Matrix

BEM vs. SMACSS

SMACSS (Scalable and Modular Architecture for CSS), developed by Jonathan Snook, organizes styles into five categories: Base (defaults), Layout (major sections), Module (reusable components), State (overrides like .is-active), and Theme (visual variations). The primary difference from BEM is organizational philosophy. SMACSS provides rules for categorizing CSS, but is flexible about naming within those categories. BEM provides strict naming rules but is less prescriptive about file organization.

Where BEM is stronger: BEM's rigid naming convention eliminates ambiguity. When a new developer encounters .search-form__input--disabled, the relationship between component, part, and state is immediately clear without consulting documentation. SMACSS's flexibility means teams must establish and enforce their own naming conventions within each category, which often leads to inconsistency as teams grow.

Where SMACSS is stronger: SMACSS's state rules (.is-active, .is-hidden) can be more readable than BEM modifiers for JavaScript-toggled states, since the state class is independent of the component name. SMACSS also provides more explicit guidance on separating layout from module CSS, which BEM leaves to team convention.

Practical recommendation: For enterprise teams, BEM's strictness is typically an advantage. The reduced ambiguity accelerates code reviews, simplifies onboarding, and prevents the "methodology drift" that occurs when flexible conventions meet large teams with varying experience levels.

BEM vs. OOCSS

OOCSS (Object-Oriented CSS), pioneered by Nicole Sullivan, organizes CSS around two principles: separate structure from skin (how a component is built vs. how it looks) and separate container from content (components should not depend on their location in the DOM). OOCSS encourages creating small, reusable CSS "objects" that compose together.

Where BEM is stronger: BEM provides a clear, enforceable naming convention. OOCSS relies on developer judgment to decide where object boundaries fall, which can create inconsistency. BEM's explicit modifier syntax also makes variant tracking straightforward in large design systems.

Where OOCSS is stronger: OOCSS's composition model produces smaller CSS files when many components share structural patterns. Rather than creating separate BEM Blocks for a bordered card, a shadowed card, and a rounded card, OOCSS composes .border, .shadow, and .rounded objects. This reduces duplication at the cost of HTML readability.

Practical recommendation: BEM and OOCSS are not mutually exclusive. Many production codebases use BEM naming for component structure while applying OOCSS principles for shared visual patterns (spacing, typography, color). The key is establishing clear guidelines for when to create a BEM Block versus when to compose OOCSS utility objects.

BEM vs. Atomic CSS / Utility-First (Tailwind CSS)

Atomic CSS, popularized by frameworks like Tailwind CSS, takes a fundamentally different approach: rather than naming components semantically, every visual property is expressed as a single-purpose utility class applied directly in HTML. A button styled with BEM as .btn.btn--primary.btn--large would be expressed in Tailwind as class="bg-blue-600 text-white px-6 py-3 rounded-lg font-semibold hover:bg-blue-700".

Where BEM is stronger: BEM produces readable HTML where class names describe what a component is rather than how it looks. This semantic clarity is valuable for teams that maintain server-rendered applications, work with designers who read markup, or need to understand component structure from HTML alone. BEM also avoids the "wall of utility classes" problem that makes complex Tailwind components difficult to scan visually.

Where Tailwind/Atomic CSS is stronger: Utility-first CSS eliminates the need to write custom CSS in most cases, dramatically accelerating prototyping and reducing the total volume of CSS shipped. It also eliminates naming decisions entirely, which removes a common source of team friction and inconsistency. For teams building with component frameworks (React, Vue), utilities composed within reusable components mitigate the HTML readability concern.

Practical recommendation: The choice often depends on your rendering model and team structure. BEM excels in server-rendered, multi-page applications where CSS is authored and maintained independently from markup. Tailwind excels in component-based JavaScript frameworks where styles and markup are co-located. For enterprise applications, the deciding factor is usually whether the team has standardized on a component framework with co-located styles (favor Tailwind) or maintains traditional CSS files alongside server-rendered templates (favor BEM).

BEM vs. CSS Modules

CSS Modules scope class names to individual components at build time, generating unique identifiers that prevent naming conflicts automatically. A class named .title in a Card component's CSS file becomes something like .Card_title_a1b2c in the compiled output, eliminating the possibility of collision with a .title class in any other component.

Where BEM is stronger: BEM requires no build tooling. It works identically in a static HTML page, a WordPress theme, a Django template, or a React application. CSS Modules require a build pipeline (Webpack, Vite, or equivalent) and are tightly coupled to component-based JavaScript frameworks.

Where CSS Modules are stronger: CSS Modules provide guaranteed isolation without any naming discipline. Teams do not need to learn or enforce a convention because scoping is handled automatically. This makes CSS Modules particularly effective for large React or Vue codebases where dozens of developers contribute components independently.

Practical recommendation: CSS Modules and BEM solve the same core problem (preventing style conflicts at scale) through different mechanisms: convention (BEM) versus tooling (CSS Modules). For teams already using a JavaScript framework with a build pipeline, CSS Modules often provide equivalent benefits with less cognitive overhead. For teams working without build tooling or across mixed technology stacks, BEM's framework-agnostic nature makes it the more versatile choice.

Making the Decision for Your Team

The "right" CSS methodology depends on your project context. Consider these decision factors:

Choose BEM when your team works with server-rendered HTML, maintains large CSS codebases without a JavaScript framework, needs a convention that works across mixed technology stacks, or values semantic HTML class names that describe component structure.

Choose Tailwind/Atomic CSS when your team uses a component framework with co-located styles, prioritizes development speed over HTML readability, wants to minimize custom CSS authoring, or builds design systems where consistency is enforced through utility constraints.

Choose CSS Modules when your team uses React, Vue, or another component framework with a build pipeline, wants guaranteed style isolation without naming conventions, and is comfortable with build tooling as a dependency.

Combine approaches when your project spans multiple rendering models (server-rendered pages alongside client-rendered components) or when your design system needs both semantic component classes (BEM) and shared utility patterns (OOCSS or Tailwind).

Regardless of which methodology you select, the most critical factor is consistency. A mediocre methodology applied consistently will produce better outcomes than a superior methodology applied inconsistently. Establish your conventions early, document them clearly, enforce them through code review, and revisit them periodically as your team and codebase evolve.

Benefits of Using BEM Methodology 

Implementing the BEM methodology in your projects offers several significant advantages: 

1. Improved Code Organization 

BEM methodology creates a clear, logical structure for your CSS. By organizing styles around components (blocks), you create a more modular codebase where each piece has a specific purpose. This makes it easier to navigate large stylesheets and quickly locate the code you need to modify.  

 main.css 

Option 2: Group related blocks 

javascript 

styles/ 

 components/ 

   navigation.css  /* Contains nav blocks and elements */ 

   forms.css       /* Contains form-related blocks */ 

 layout/ 

   grid.css 

   containers.css 

 main.css 

BEM with Preprocessors 

CSS preprocessors like SASS or LESS work exceptionally well with BEM methodology. They allow for nesting, which can make your BEM code more readable: 

scss 

.card { 

 border: 1px solid #ddd; 

  &__header { 

   background-color: #f8f9fa; 

 } 

  &__title { 

   font-size: 18px; 

 } 

  &__body { 

   padding: 15px; 

 } 

  &__button { 

   background-color: #007bff; 

   &--secondary { 

     background-color: #6c757d; 

   } 

 } 

} 

This approach keeps the BEM structure while making the code more concise and easier to read

Common BEM Challenges and Solutions 

While BEM offers many advantages, you may encounter some challenges when implementing it. Let's address the most common issues and their solutions. 

Challenge 1: Handling Deeply Nested Elements 

Problem: BEM doesn't recommend nesting elements within elements (like .block__element1__element2). This can be challenging for complex interfaces. 

Solution: Instead of nesting elements, consider creating a new block for complex components that could stand on their own. For example, rather than .card__header__title, you might use .card-header as a new block with .card-header__title as its element. 

Challenge 2: Managing Component States 

Problem: How to handle states that are applied dynamically, like hover states or focus states. 

Solution: For pseudo-states like :hover or :focus, use standard CSS pseudo-selectors rather than creating modifiers: 

css 

.button { 

 background-color: blue; 

} 

.button:hover { 

 background-color: darkblue; 

} 

For states that change based on user interaction or application state (like "expanded" or "selected"), use modifiers: 

css 

.accordion__item--expanded { 

 height: auto; 

} 

.nav__link--selected { 

 font-weight: bold; 

} 

Challenge 3: Long Class Names 

Problem: BEM class names can get lengthy, especially with longer block or element names. 

Solution: Keep your block and element names concise but meaningful. You don't need to include every detail in the class name if the purpose is clear. For example, use .user-menu__item instead of .user-navigation-menu__list-item.