The BEMIT naming convention

My selfie

James Turner,

Tags: CSS HTML

Giving this site a spring clean has been in my sights for some time. It's only when I take a look at the HTML and CSS (not Sass yet—that's pencilled in for later in the year) that I realise how difficult it is to org­anise and maintain, even on a small, one-person website like this. For example, there's a class that I simply called structure. Structure of what? I obviously wasn't feeling generous towards future-me on the day I came up with that. It's going to take some digging to figure out what it's for.

On his CSS Wizardry site, talks a lot about naming conventions and approaches to organising markup to keep it clean and maintainable, parti­cularly for large teams. I'd like to spend the next few blog posts lifting the bonnet on CSS Wizardry, and this first post is about Roberts' latest innovation, the BEMIT naming convention.

Skip to navigation

A distinguished pedigree

BEMIT is a concatenation of BEM, the block-element-modifier naming convention, and Harry Roberts' own ITCSS (Inverted Triangle CSS) approach to structuring style sheets. This video, Harry Roberts—Managing CSS Projects with ITCSS (YouTube), gives an in-depth account of his proposed method, and this article in Net magazine (issue #267, June 2015) also outlines it. So, what are BEM and ITCSS?

BEM: Who's your daddy?

Now that we're seeing more of a tendency to structure web content into pat­terns, rather than pages, the BEM model for naming seems to fit quite nicely. The principle is based on being able to identify blocks of content, such as the ‘Recent Posts’ teasers on the home page of this blog. We might call one of these teaser.

Within this block, there will be related elements, such as the title of the article, the date it was published, a description of the content, and a ‘Read more’ link. Accord­ing to the BEM model, we should name these using the containing block name, two underscores, and then the element name. This gives us teaser__title, teaser__date, teaser__description and teaser__read-more.

There might also be situations where a teaser needs special styling. For example, I might want the latest teaser to have a different background colour, or to say “New!” at the beginning. For this, BEM says I need a modifier, which I refer to with the block name, two hyphens and the modifier name: teaser--latest.

So, the teaser for the post you're reading right now might have this markup:

<div class="teaser teaser--latest">
  <h2 class="teaser__title">The BEMIT naming convention</h2>
  <time class="teaser__date" datetime="2016-01-05">05 January 2016</time>
  <p class="teaser__description">Trying to keep CSS tidy and
  transparent is never easy, especially on large projects.
  Fortunately, Harry Roberts' CSS Wizardry is there to help us.
  In advance of my site redesign, I take a look at his BEMIT approach to 
  naming elements and keeping CSS organised.</p>
  <a class="teaser__read-more" href="bemit-naming-convention.html">
  Read more</a></p>
</div>

I wonder whether all of these classes are really necessary. For example, if I want to style the heading within a teaser, I could use .teaser h2 {}. Surely, I'll remember six months or two years down the line what .teaser h2 {} is, right? I suppose the argument goes that, yes, the BEM approach might be overkill for a pissant little web­site like this one. But, if you're working on a large project with tens of des­igners and a high staff turnover, you need an idiot-proof way of referring to ele­ments in your HTML and CSS. It may be perfectly obvious to me what .teaser h2 is, but it might not be obvious to that new recruit who's just blagged herself on to the team.

Skip to navigation

ITCSS: Who's your second daddy?

If we're going to use a naming convention like BEM, we should think about how we're going to keep all these elements and blocks tidy in our style sheets. I have an idea: let's organise it into typography, layout, colours and…er…misc, OK? Mmm. That might be fine for a small site like this (and as the guy who main­tains this site, I can tell you there's nothing fine about it), but I imagine when you're working on a big project, this kind of arbitrary approach is quickly going to get messy.

Thankfully for dumbos like me, ITCSS puts forward an alternative. The ‘inverted triangle’ is a metaphor for the scope and specificity of elements in the style sheet. At the beginning of the style sheet, we want the big, global definitions, such as @includes and other external, ‘admin’ links. After that, we want site-wide global styles, like * {} and body {}. Next, it's styles that effect common elements; this is where you define all the paragraphs in your site p {} and all the links a {}. Resets, if you worry about that kind of thing, presumably go in this position (you can read about the merits and drawbacks of CSS resets here, here and here).

Now we're getting more specific. Next comes styling for our reusable patterns. It's here that I style the elements I created above: .teaser {}, .teaser--latest {}, .teaser__title {}, and so on. Then, I style unique elements, such as the site logo or main navigation: .logo {} and .nav {}. I suppose these are arguably “reusable patterns”, but they're unique in the sense that that they only appear once on any given page. At the bottom of the style sheet, we have what Roberts calls ‘trumps’, which are those grubby little styles that have !important after them.

The inverted triangle has seven layers, from top to bottom, settings, tools, generic, elements, objects, components and trumps.
Figure 1: The inverted triangle is a metaphor for the scope and specificity of a style—global styles towards the top, and specific styles towards the bottom. (Image used without permission.)

With ITCSS, instead of asking “am I styling the colour or the typography here?”, I ask “What's the scope of the element I'm styling?” If it's an element that appears everywhere on my site, such as a paragraph, I know it's somewhere towards the top of the style sheet. If I'm styling a pattern that only appears on one page, like my teaser, I know it'll be towards the bottom. Roberts argues that this kind of struc­ture makes it far easier to maintain and collaborate on style sheets, espec­ially when combined with CSS preprocessors like Sass.

I believe Harry Roberts is working on a book about all this, so watch this space. And .

Skip to navigation

Extending BEM and ITCSS

With BEM and ITCSS, we have a set of guidelines that describe how to name classes and where to put them in a style sheet. This is probably enough for small-scale projects. But there are still problems to be solved. What about the scope of ele­ments? A name like teaser gives me an indication of what it does, but it doesn't tell me how important it is to the website as a whole. Maybe I know that it only appears on the ‘recent posts’ page, but does Jane Bloggs, who works on the other side of the world? And what about responsive web design? Occasion­ally, it's going to be handy to give a class to an element so that we can explicitly say what it does at different screen sizes. Again, it's not nec­essarily for me; it's for Ms Bloggs, who is a great designer, but not a mind reader. In BEMIT: Taking the BEM Naming Convention a Step Further, Roberts proposes extensions to BEM and ITCSS that address these issues.

Namespace prefixes

To address the issue of scope, Roberts suggests we use namespace prefixes. Does the element potentially appear on every page of the site? If so, it's probably an object, and should have an o- in front of it. An example might be a block that contains a responsive image and its corresponding caption, which we give the class o-image. Is the element repeated, but only used on one particular page, such as the teasers on the ‘Recent Posts’ page of this site? Then it's probably a component, and should take the prefix c-, for example, c-teaser.

Another prefix is u- for utilities, classes which might be a bit ‘breaky’, but just make it easier to achieve certain results, such as centring text in a couple of elements (u-text-centre). Further such class prefixes are t- for themes; s- for scope; is- and has- for temp­orary states; _ for outright hacks; js- for classes which influence the behav­iour of the element through JavaScript; and qa- for styles related to quality assurance. The link above describes each of these situations in detail.

[Thinking more about this, it seems that component and object prefixes could go further. There are two questions we could ask about the scope of an element: how many pages does it appear on, and how many times could it appear on a given page? Thinking about the elements on a typical blog website, we could divide them as follows:

Appears on several pages, potentially several times per page:

Appears on several pages, once on each page:

Appears on one page, several times:

Appears on one page, once:

How this fits in with components and objects, I'm not sure, but using an element's class to indicate its scope within this framework could be really useful on large projects.]

Anyway, what a great idea! Just by looking at prefix on a class, we can guess at the effect that tinkering with the styles might have on the site. If Jane Bloggs sees an element with an o- prefix, she'll know to tread lightly. But if she sees a c- prefix, she can fill her boots. This could save a lot of head-scratching when it comes to maintaining a site.

Skip to navigation

Responsive suffixes

The second way that Roberts suggests to extend BEM is to add a suffix, preceded with @, which is targetted at media queries. For example, c-teaser@sm gives us a hook to style my teaser block at small screen widths, while o-image@print is a class that allows us to style an image object for print. One important point, the @ symbol has to be escaped in CSS, so you'd write it like this: .c-teaser\@sm {}.

I'm not experienced enough as a web designer to appreciate the value of resp­onsive suffixes. Say I want to style my teaser at smaller screen widths. Wouldn't this be enough?

@media screen and (max-width: 35em) {
    .c-teaser {
        /* styles go here */
    }
}

Perhaps if we're being idiot-proof to the max, it might be necessary. I sup­pose simply by giving an element a class with a responsive suffix, we're informing the designer that something happens at this screen size, so watch out.

Skip to navigation

Recap

Let's have a quick quiz. What do these three classes mean?

  1. c-teaser--latest@sm
  2. o-image__caption@print
  3. u-clearfix

The first one is our teaser. Thanks to the c- prefix, we know it only appears on one particular page. If we tinker with it, it's probably not going to impact the whole site. Also, it's not just any teaser; it's the latest. It will probably be styled slightly differently to the other teasers on the page. We also know that this class is to be used for styling the teaser at small screen widths.

The second class is a caption for an image. From the o- prefix, we know it could appear on several pages across the site. The @print suffix also tells us that this class is intended for styling the element in print.

Finally, we have a good old clearfix utility. Use this on an element to fix the layout after using floats.

Skip to navigation

Conclusion

BEM gives us a much clearer system for communicating the relationships between blocks and the elements contained within. It's semantic and meaningful, so it is standards-compliant. To summarise BEM:

ITCSS gives us a system for structuring style sheets which makes it much easier to locate styles. By thinking about a style's scope, rather than its function, we can decide where to put it in our style sheet. This also makes it easier when we come back to it months later, or pass it on to a colleague.

BEMIT blends the idea of blocks, elements, and modifiers with the notion of scope. In summary:

Used alone, a system like BEM or ITCSS can greatly improve the transparency and maintainability of our markup. Used together, they are extremely powerful indeed. And with BEMIT, we are giving designers and developers even more at-a-glance information about what styles are doing. The gains in terms of frustration avoided and time saved figuring out what classes do should be substantial.

Skip to navigation

Further reading

SMACSS. Very much an earlier iteration of ITCSS, Scalable and Modular Architecture for CSS, an approach to structuring CSS by , is worth a look. Like ITCSS, SMACSS advocates working with the cascade by using semantic class names and organising elements in a style sheet by scope. There is an earlier edition of the SMACSS book available to read online.

SUIT, by , is another CSS-structuring approach which focusses on semantic naming and good dependency management. There's a fantastic Related Reading section at the end.

Skip to navigation