Taking the BEM Naming Convention a Step Further – CSS Wizardry

5 August, 2015

Written by Harry Roberts on CSS Wizardry.

Anybody who’s followed me or my work for any length of time will no doubt know
that I’m a huge proponent of the BEM naming
convention.
What I’m about to talk about in this post is not an alternative or different
naming convention to BEM, but an augmentation: small additions that level BEM up
a notch. This extended BEM syntax has been dubbed BEMIT, as it borrows
some paradigms and patterns from the (as yet unpublished) Inverted Triangle CSS
architecture. BEM + ITCSS = BEMIT.

For a quick recap on BEM, it works by breaking all classes in a codebase down
into one of three groups:

• Block: The sole root of the component.
• Element: A component part of the Block.
• Modifier: A variant or extension of the Block.

Blocks, Elements, and Modifiers: BEM. Absolutely every class in a project fits
into one of these categories, which is why BEM is so great—it’s incredibly
simple and straightforward.

The point of BEM is to give a lot more transparency and clarity in your markup.
BEM tells developers how classes relate to each other, which is particularly
useful in complex or deep pieces of DOM. For example, if I were to ask you to
delete all of the user-related classes in the following chunk of HTML, which
ones would you get rid of?

 class="media  user  premium">
  





 src="" alt="" class="img  photo  avatar" />
  



 class="body  bio">...

Well we’d definitely start with user, but anything beyond that would have to
be a guess, educated or otherwise. However, if we rewrote it with BEM:

 class="media  user  user--premium">
  





 src="" alt="" class="media__img  user__photo  avatar" />
  



 class="media__body  user__bio">...

Here we can instantly see that user, user--premium, user__photo, and
user__bio are all related to each other. We can also see that media,
media__img, and media__body are related, and that avatar is just a lone
Block on its own with no Elements or Modifiers.

This level of detail from our classes alone is great! It allows us to make much
safer and more informed decisions about what things do and how we can use,
reuse, change, or remove them.

The one thing missing from BEM is that it only tells us what classes to in
relative terms, as in, how classes are related to each other. They don’t
really give us any idea of how things behave, act, or should be implemented in a
global and non-relative sense.

To that end, I decided to extend BEM to become BEMIT. BEMIT doesn’t add any
other types of class—we still only ever have Blocks, Elements, or Modifiers—but
it does add usage and state information.

Namespaces

So as not to repeat myself, it’s probably best you refer to my post from earlier
this year, More Transparent UI Code with
Namespaces,
in which I introduce the idea of prefixing every class in a codebase with a
certain string in order to explain to developers what kind of job it does. This
Hungarian notation-like
naming allows us to ascertain exactly what kind of job a class might have, how
and where we might be able to reuse it (if at all), whether or not we can modify
it, and much more. The linked article is pretty sizable, but will give you a
whole load more insight into the technique.

The most common types of namespace are c-, for Components, o-, for
Objects, u-, for Utilities, and is- or has- for States (there are
plenty more detailed in the linked post). With this in mind, the above HTML
would be rewritten as this:

 class="o-media  c-user  c-user--premium">
  





 src="" alt="" class="o-media__img  c-user__photo  c-avatar" />
  
 class="o-media__body  c-user__bio">...

From this, I can see that we have a reusable abstraction in the Media
Object
(o-media*) and two implementation-specific components (c-user* and
c-avatar). These classes are all still Blocks, Elements, or Modifiers: they
haven’t added a new classification, but have added another layer of rich
meaning.

These namespaces tie in with the layers found in the Inverted Triangle CSS
architecture, meaning every class has a specific place to live in our project
(and on our filesystem).

Responsive Suffixes

The next thing BEMIT adds to traditional BEM naming is responsive suffixes.
These suffixes take the format @, and tell us this class when
at this size:

 class="o-media@md  c-user  c-user--premium">
  





 src="" alt="" class="o-media__img@md  c-user__photo  c-avatar" />
  
 class="o-media__body@md  c-user__bio">...

So here we have o-media@md, which means be the media object at this
breakpoint. Other possible examples:

• u-hidden@print – a utility class to hide things when in print context.
• u-1/4@lg – a utility to make something a quarter width in the large
  breakpoint.
• o-layout@md – a layout object in the medium breakpoint.

The @ is a human readable and logical way of denoting conditional states. It
allows developers to learn about any potential permutations or appearances that
the piece of UI in question might have, just at a glance.

N.B.: You have to escape the @ symbol in your CSS file, like so:

@media print {

  .u-hidden\@print {
    display: none;
  }

}

Healthchecks

By having these strict and consistent patterns in our HTML we can do a number of
things. Firstly, and most obviously, we can write much more expressive and rich
UI code for our colleagues, meaning they can learn and reason about the state
and shape of a project much more quickly. They can also contribute in the same
consistent manner.

But another happy side effect we get is that we can run a visual healthcheck
against our UI. By using substring selectors, we can target and then visualise
the general makeup of a page based on the types of class it contains:

/**
 * Outline all classes.
 */
[class] {
  outline: 5px solid lightgrey;
}

/**
 * Outline all BEM Elements.
 */
[class*="__"] {
  outline: 5px solid grey;
}

/**
 * Outline all BEM Modifiers.
 */
[class*="--"] {
  outline: 5px solid darkgrey;
}

/**
 * Outline all Object classes.
 */
[class^="o-"],
[class*=" o-"] {
  outline: 5px solid orange;
}

/**
 * Outline all Component classes.
 */
[class^="c-"],
[class*=" c-"] {
  outline: 5px solid cyan;
}

/**
 * Outline all Responsive classes.
 */
[class*="@"] {
  outline: 5px solid rosybrown;
}

/**
 * Outline all Hack classes.
 */
[class^="_"] {
  outline: 5px solid red;
}

Of course this isn’t bulletproof—something might be both a Component and an
Element and a Responsive class—but if we write the classes in pretty selective
order (i.e. in the order of least to most important to know about, hence Hacks
coming last), we can begin to get a nice visual snapshot of the makeup of any
given page. You can read more about the benefits of this highlighting in my
previous article about
namespaces.

We can enable this healthcheck in multiple ways, but the simplest would probably
be nesting the whole lot in a Scope
class:

.s-healthcheck {

  ...

  /**
   * Outline all Responsive classes.
   */
  [class*="@"] {
    outline: 5px solid rosybrown;
  }

  ...

}

…which you can then add to your html element when you want to turn it on:

Final Word

So there we have it, a couple of simple additions to BEM to turn it into BEMIT:
adding information onto the beginning and end of the standard Block, Element, or
Modifier classes to give us more knowledge about how the classes behave in a
non-relative sense. Some more examples:

.c-page-head {}

@media screen and (min-width: 15em) {
  .u-text-center\@sm {}
}

.o-layout__item {}

@media print {
  .u-color-black\@print {}
}