BEM (CSS)? about start-here

[iteles]

Note: A slightly clearer article on BEM specifically in CSS: http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/

I've been thinking about how best to formalise this into a strict style we can use throughout.
I see the merits of BEM, chiefly that it's always immediately apparent where the element that a class is styling fits within the document hierarchy - you always know how each block, element and modifier relate to each other.

However, it does create a relatively rigid structure that is fiddly to alter down the line because blocks and elements are so bound together. For a very lean, iterative process, this feels more painful than useful for now.

I think we should use the modifier convention but we'll need to review the block__element convention.

@msmichellegar @NataliaLKB, as two organised people who have experience of CSS, what do you reckon?

[olizilla]

I feel BEM trades off flexibility for predictability. It reduces the burden of understanding css selector specificity so it can mean fewer surprises for teams all hacking on the same styles.

I don't enjoy working with BEM, but probably because I haven't fully let go of the (possibly just as harmful) dream of semantic mark-up. I'm most curious to see where this issue leads.

[iteles]

@olizilla Cheers for the thoughts, good to know!

[msmichellegar]

Interesting! I've never heard of this before, but it looks very logical. I like your idea @iteles, of using modifiers, but reviewing block__element. I feel like it'd be good to be able to move elements around freely later down the line if we want to experiment with different UI/UX.

[iteles]

Still trialling this at #dwylsummer.

[howardroark]

My view on BEM is that it will make no sense to you until you have worked on a very complex UI with a large team and experienced those pain points. Just like @iteles mentioned, it is very fidgety to alter and does not lend itself well to a "loose" process. You can end up having endless semantic arguments.

If you were working on a team that was asked to spend a year planning, designing, wire framing, and developing an entire redo of bbc.co.uk then it would likely be the teams best friend. I feel it works best in a very "waterfall" hierarchical type of setup.

[iteles]

Thanks for the input @howardroark 😊 Have you ever had the chance to use it yourself on a project?

[howardroark]

Yes. It was actually quite enjoyable during the initial development stage. As @olizilla mentioned it is a nice stand-in for semantic markup while appeasing a complex UI design. It was not much fun after the client feedback started to roll-in and things needed to change quickly leading up to the deadline. A lot of what you were proud of becomes "undone".

I think it was conceived to compliment teams who are running and maintaining large marketing based sites that goes through planned periodic updates.

[iteles]

Really useful to get your take on this @howardroark, thanks!
We totally agree. Our style guide (in progress) currently states we use BEM modifiers but semantic markup otherwise and we very much feel that that's the right solution for us at the moment. Flexibility is key 👍

[iteles]

Added what's currently right for us to the style guide, as per comment above ➡️ dwyl/style-guide@dea0009?diff=split#diff-04c6e90faac2675aa89e2176d2eec7d8R83 👍

[NataliaLKB]

Though I am a bit late replying to this thread (as it is now closed) it is an interesting topic.

We use BEM at the guardian and I do see why it is done... It is predictable, and there aren't very many surprises, but I do find it can make our templates quite messy as class names get longer and longer. That said, since we have such a big site, it is very beneficial to have a clear picture of everything I am changing simply based on the name of the class.

In my next personal project (or with you guys) I would very much like to try using BEM modifiers potentially without the block__element as I find that can result in repetition in the code which I would prefer to avoid.

The talk on BEM that happened yesterday at the London AJAX meetup was very informative, but didn't go in depth in the pros and cons of each approach. Here are the slides if you are interested.