How we use BEM to modularise our CSS
Andrei Popa
724

It might look cleaner for the simple structures, but for example:

  1. You have to hard-code the separators. if you have a couple of elements and a couple of modifiers for a block, those dashes and underscores won’t look as good anymore.
    There’s also the possibility you’d want to change the way class names are generated in another project — e.g use single dash and single underscore, naming your modules with .block_innerElement or .block-isHighlighted. It’s not something that happens all the time, but it just highlights the flexibility of working with mixins instead of plain SASS.
  2. You won’t be able to generate the proper class names for elements defined within block modifiers
    So for an element defined within a block modifier, there are not many options to do it without using extra variables to hold the block selector (&). The easiest way would be to define the parent selector twice
.block {
&--modifier &__element {
...
}
}

An example for the second point would be defining an item in the context of a grid or list display for a block.

So taking the structure

block: products
block-modifier: grid
block-modifier: list
block-element: item 

The CSS that we need for the item would be

.products--grid .products__item {
width: 20%;
}
.products--list .products__item {
width: 100%;
}

with the mixins you would just define

@include block(‘products’) {
@include modifier(‘grid’) {
@include element(‘item’) {
width: 20%;
}
}
  @include modifier(‘list’) {
@include element(‘item’) {
width: 100%;
}
}
}

We have edge cases like this all the time, so the mixins save us time when building the stylesheets.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.