Should we use BEM?

[BenjaminRCooper]

Just going to kick this off, as I know its going to be this weeks biggy.

If so, why and how? do we adopt just general BEM principles or do we adapt?

B

[markgoodyear]

After using BEM, I enjoy how it can help make the code more readable, structured and modular.

Example 1:

<label class="input">
    <span class="input__label">Some Label</span>
    <input class="input__text" name="some-name" type="text" >
</label>

Take the above, you can instantly tell that the <span> is part of the class .input and should only be used inside it.

Example 2:

<label class="input">
    <span class="label">Some Label</span>
    <input class="text" name="some-name" type="text" >
</label>

Same example without BEM. The class names get lost without the prefix as it's not easy to see that .label belongs inside .input.

Having said that, not everything should use BEM if it doesn't require it. Example 2 can still be perfectly fine, if the use case of .text or .label is used outside of .input.

In short: I'd say use BEM, but only when it fits and makes sense too.

[timgale]

I think we should go with it, but be sparing with it's use. For example thinking carefully about extending namespaces; things can quickly get messy and too specific when you are working upwards of three elements deep.

[BenjaminRCooper]

If we are going to work in a modular enviroment, I would like to use BEM, as it works and from a visible aspect it makes a lot of sense.

I agree with both, use it sparingly, and then for anything else, keep to using dashes to seperate words within class names, e.g. some-class.

It is that line of understanding if a module can be encapsulated or if child entities can be used in multiple contexts.

I think this comes with more planning up front and understanding your project and the designers vision.

B

[jonspark]

Very much a fan of BEM, with a bit of SMACSS mixed in. It's easily readable and, once you understand the basic rules (Blocks, Elements & Modifiers), it's easy to see how each relates to one another.

The biggest advantage, I feel, is the relationship between You and Future You (who may also be someone else). It's easier for Future You to tell what is going on and how things relate. You have to plan your chunks of page out, keeping reusability in mind.

It just seems to reduce the WTF's and, generally, aids the extendability as you know that you're not going to have to deal with higher styles cascading down on your new module.

[BenjaminRCooper]

Totally agree mate. I'm with you.

B

[BenjaminRCooper]

+1 with @jonspark

[BenjaminRCooper]

What is everyones thoughts on this?

I am very much with @jonspark, but I would love to hear opinions, as this will be the standard adopted and implemented into the boilerplate.

B

[lewismorris]

Jon has hit the nail on the head for me, i think when writing with BEM it makes you think more about what you are writing and in turn IMO turns out better code. Big +1 for me on using BEM.

Just out of interest @Passenger-Inspired in what way would you like us to implement BEM into the boilerplate?

[timgale]

+1

[BenjaminRCooper]

Not sure mate, that is something we should discuss within the issue.

Within the boilerplate, I feel it is only ever necessary to use BEM on modules/abstractions .e.g. nav, media etc

B

[lewismorris]

Hey Ben,

I Agree it should only be used on Modules/Abstractions, would we define this as just a rule though? I don't think it's necessary for us to be include pre-written code into the boilerplate?

[BenjaminRCooper]

No not at all mate.

Think we just need to make it clear of the use in which we write modules.

Once we are all in agreement in the approach (to BEM or not to BEM), its a methodology and understanding when to use the approach will only come with experience.

Not something we can really document, its more of an approach we look to achieve, and then its down to everyone to keep planning their documents and understanding the project they work upon, so they can understand what elements are worth making modular.

B

[BenjaminRCooper]

I just want to add something to this, to mix it up a little.

I looked at SUIT from Nicolas Gallagher, and I'm hugely impressed with the approach he has implemented.

What impresses me most, is his use of Utility classes, and how he categorises them based one their use case e.g. text, layout etc.

I'm not a fan of his naming conventions, as he mixes different solutions e.g. hyphens, camel case, but I would love to have something like this within the boilerplate.

So with all this said, here is my thoughts on implementing BEM as a team;

• We use BEM sparingly. We should plan our documents beforehand and understand where are the places BEM could be implemented and what patterns are contained within the designs provided. Understanding that patterns are do not have to just be visual is key.
• In the case of not using BEM, we use hyphens and lowercase words to create class names for global items.

What do you guys think?

B

[lewismorris]

+1. Good Call @Passenger-Inspired

[BenjaminRCooper]

You MUST use BEM notation to name and structure your objects.

BEM is the methadology we have choosen as a team to follow, and moving forward we hope to adapt our style as and when is necessary.

Whilst it is required you use BEM to create your modules, it is recommended that you spend time upfront to understand your project structure and plan your reusable components.

As stated, it is required that you use BEM for specifically modules, but when it comes to global elements, you should use hyphenated, lowercase words to create your class names, like so;

Example:

<div class="some-global-element"></div>

This means that you use BEM sparingly, and only in situations where you feel patterns and abstractions exist.

Resources:

A New Front-End Methadology: BEM (http://coding.smashingmagazine.com/2012/04/16/a-new-front-end-methodology-bem/) Fifty Shades of BEM (http://blog.kaelig.fr/post/48196348743/fifty-shades-of-bem)

[BenjaminRCooper]

Implemented