Exploring our changes in more detail

It is worth taking time to really get familiar with BEM styling principles. This is one of those areas where not spending time can easily dissuade you from using this technique; the principles are easy to understand but can take time to implement! Let's take a look at our code in more detail.

The key principle around BEM, when using the PostCSS plugin, is that of nesting—in this instance, we create our core component content, which results in an empty style rule at the top of our style sheet. Indented to the next level is our @descendant—this indicates that our message boxes are being styled as alerts. We then use a number of @modifiers to style each type of alert, such as success, warning, error, or notice (that is, information). This includes a separate style rule to cover each instance of the hover pseudo-element used in our code.

What does this mean for us? It means we have to not just consider each element (for instance, a message box) as a single entity to which we simply apply lots of classes; instead, we should consider the constituent parts of each element and apply a single class to each. Hold on, does that not mean we still have three classes in use (as we might have here)?

Tip

To learn more about BEM naming conventions, take a look at the useful article posted at https://en.bem.info/tools/bem/bem-naming/.

Well, the answer is yes, and no: the trick here is that PostCSS will combine each nested style into valid CSS; for example, this extract (adapted from our demo):

@component content {
  @descendent alert {
    font-family: Tahoma, Geneva, Arial, sans-serif;
    font-size: 0.6875rem;
    color: #555;
    border-radius: 0.625rem; 

    @modifier error {
      background: #ffecec url("../img/error.png") no-repeat 0.625rem 50%;
      border: 0.0625rem solid #f5aca6; 
    }
  }
}

When compiled, this will appear as this CSS:

.content {}
.content__alert {
    font-family: Tahoma, Geneva, Arial, sans-serif;
    font-size: 0.6875rem;
    color: #555;
    border-radius: 0.625rem;
}
.content__alert_error {
    background: #ffecec url("../img/error.png") no-repeat 0.625rem 50%;
    border: 0.0625rem solid #f5aca6;
}

The sharp-eyed among you will have spotted that we still have errors being generated when our code is compiled:

It's always disconcerting to see errors, but there are valid reasons for them. We can safely ignore the two deprecation warnings (these should be fixed in a future version), but the two errors are of more concern.

Fixing our errors

The two errors are being caused by postcss-bem-linter, which is not recognizing the two styles as valid BEM notation. This raises a question: can we alter our code to remove the issues?

To answer this, we would need to weigh up how much code is affected against the time and effort required to alter it. In our demo, there is very little code affected; to resolve it, we would need to alter the .dlgBox and span styles to equivalent BEM naming.

Is this worth the effort? In a small demo such as ours, it is likely that the answer is no, for a larger demo, we would look to alter these two styles. Instead, we can add a simple directive at line 48, thus:

When the code is recompiled, the errors are removed:

Purists may say this is cheating. It's true, our code is still technically not all BEM. In defense though, it's up to each developer to make that decision; there may be elements that have to remain as standard CSS, which we can't convert. In this case, it may be sensible to import these styles using the PostCSS import plugin—we will explore using this more in Chapter 10, Building a Custom Preprocessor.

It's worth noting that the postcss-bem-linter plugin will not display the results of any errors by itself—for this, we need to use a plugin such as postcss-reporter (available at https://github.com/postcss/postcss-reporter, for command line), or postcss-browser-reporter (from https://github.com/postcss/postcss-browser-reporter, displays content in the browser window). Both have a number of options that are worth investigating to help fine-tune what is displayed when the code is processed through PostCSS.