[matthewlein]

Their modified BEM choice is surprising. I think BEM works best when the dividers have meaning. In their examples its impossible to know what is a modifier vs an...element? I don't get it from the examples.

  .accordion
  .accordion-item
  .accordion-item-selected

  .nav_bar
  .nav_bar-link
  .nav_bar-link-clicked

Though its the most ugly, I'm a fan of the original B__E--M

[Nadya]

>Though its the most ugly, I'm a fan of the original B__E--M

I feel this is something people need to learn to look past - because I agree entirely. It looks terrible. Absolutely terrible. Names get long (but yay for autocompleters!) - but everything is readable. CSS shouldn't be aesthetic. It should be legible. Maintaining something you can't read is hell - every programmer knows this.

I also make use of prefixes to namespace. Which makes my classes even longer. [0]

But there is absolutely no question what my code is doing when I read the HTML. I know exactly where changes need to be made. My coworkers are familiar enough with my style that they know what code is safe to change and what code will have side effects. They're slowly adopting the style - although it's almost a 180 from the old style of "be as specific as possible so you don't accidentally break something someone else had worked on 8 months ago". (#NotEvenKidding .our .selectors .are > .like .this)

[0] http://csswizardry.com/2015/03/more-transparent-ui-code-with...

[hire_charts]

Agreed. There is no need to use a custom flavor of BEM.

You might be able to enforce a distinction between elements and modifiers (with elements nested below parents, while modifiers are siblings of the elements they modify) like so:

  .accordion {
    .accordion-item { }
    .accordion-item-selected { }
  }

But this requires nesting where true BEM otherwise avoids it.