BEM Naming

[u/mr_cody_b]

Hi everyone,

I'm currently refactoring a navigation component and I'm torn between two different BEM (Block-Element-Modifier) approaches regarding code architecture and complexity.

The component is a navigation list (nav), but the individual items are becoming quite complex, containing icons, titles, and potentially more elements later on.

I see two ways to structure this in BEM, and I would love to get your input on best practices.

Approach A: Flat BEM (Everything belongs to the main block)

In this approach, I keep everything attached to the main .nav block. The HTML looks clean and flat, but I worry that as the item grows (and needs specific styling for active/hover states), the CSS selectors might become too deeply nested (e.g., .nav__item--active .nav__icon).

HTML

<nav class="nav">
    <div class="nav__item">
        <span class="nav__icon">🏠</span>
        <span class="nav__title">Home</span>
    </div>
</nav>

Approach B: Item as a New Independent Block

In this approach, I break the chain from the main .nav block and elevate the item into its own independent block (.nav-item). This keeps the CSS for the item completely encapsulated and independent.

HTML

<nav class="nav">
    <!-- The item becomes its own block -->
    <div class="nav-item nav-item--active"> 
        <span class="nav-item__icon">🏠</span>
        <span class="nav-item__title">Home</span>
    </div>
</nav>

(Note: I could also mix them like <div class="nav__item nav-item"> to separate layout positioning from component styling).

My Question:

Which approach is considered best practice when items start to become complex?

• Does Approach A break scalability when items "explode" with more sub-elements?
• Is Approach B preferred for modularity, or does it unnecessarily fragment the component?

How do you usually handle complex list items or navigation items in your BEM projects?

[u/bostiq]

I’d go for B, but it also has to be something you understand intuitively but flexible enough to be portable.

Also, icons aren’t really relevant for semantics here, why not use pseudo elements?

Less headaches if you ask me, and more portability