CSS: The BEM Methodology CSS: The BEM Methodology

CSS: The BEM Methodology

by ,
on 14 February 2017

0
0

For the longest time, CSS was known to be a difficult language to maintain, where the slightest modification could be critical and where everybody kinda did their own thing.
Starting with that hypothesis, these methodologies were designed to make a web site’s style sheets more legible and maintainable. OCSS is one, BEM is another. Each of these methodologies has its advantages and inconveniences. At altima°, we made the decision to choose the BEM methodology, for “Block Element Modifier” as it best corresponds to the development we wanted to adopt: a modular philosophy.
Not that long ago, il was common to see this type of CSS code:

#css
#header .nav {
max-width: 90rem;
margin: 0 auto;
}
#header .nav li {
display: inline-block;
width: 20%;
}
#header .nav li a {
color: #000;
text-decoration: none;
}

 

The problem with this type of code is multiple:

  • It’s difficult to reuse (unique ID)
  • Difficult to modify (cascade too deep)
  • Too dependent on the HTML structure
  • Not very legible
  • Less efficient (painting is more rapid if the CSS selector is simple)

The BEM methodology makes it possible to solve these problems by relying on CSS classes and avoiding nesting these as much as possible.

But before taking a look at what our example would become in BEM, let’s take a step back to talk syntax.
What you need to know is that official recommendations are available on the site en.bem.info
That being, for me, BEM is more a philosopy than a methodology with a set syntax. That’s how different variations of the syntax were proposed and used for preference sake essentially in terms of legibility.

At altima°, we opted for the following syntaxes:

#css
.Block
.Block--theModifier
.Block-theElement
.Block-theElement--theModifier

 

Let’s decrypt this syntax:

The Block systematically starts with a capital letter which is reminiscent of the syntax adopted for object programming classes.
The hyphen is used for the element and the double dashes are used to add the modifier. You’ll also note that we use CamelCase in the event where we may need to place several words in a Block, an element or a modifier.

We’re straying a little away from the recommendation (we use the hyphen instead of the underscore for the elements) but the syntax is a little lighter.
You’ll also note that we also use a prefix of 2 or 3 letters maximum in front of the class name so as to create a kind of namespace which prevents conflicts  that could appear with external resources that are often difficult to control.

In practical terms, here is what the above example gives when rewritten based on our methodology:

#css
.pre-Nav {
max-width: 90rem;
margin: 0 auto;
}
.pre-Nav-item {
display: inline-block;
width: 20%;
}
.pre-Nav-link {
text-decoration: none; 
color: #000;
}

 

It’s easy to see here that we’re talking about an item and a link (elements) that can be found in the Nav component (Block) and in the namespace “pre”.

Now let’s admit that we want to change the style for one link only, for example for an active state. We add a new class, a “modifier” type on the link:

#css
.pre-Nav-link--active {
font-weight: bold;
}

 

In reading the style sheet, it’s quickly easy to understand what it concerns and the maintainability is largely simplified. And we’re no longer dependent on the HTML tags.

And if this type of methodology is paired with a preprocessor such as SASS or LESS, we’ll get a complete modular approach as concerns dressing of Internet sites that we design at altima° but’s that’s a story for anothe article.

tags:

, ,

to read next...

Leave a Reply

Your email address will not be published. Required fields are marked *