Hacker News Reader

Comment by allendoerfer | Hacker News Reader

Is there a reason beyond the marginal performance difference, why there are no global modifiers in BEM?

I find the c-button c-button--primary a bit annoying. Why not just c-button primary and define them like this?

    .c-button.primary {
      …
    }

Or namespace it:

    .c-button.m-primary {
      …
    }

View on HN

It's not so much about performance, it's about specificity. To override anything in `.c-button.primary` you'd need something to have equal or greater specificity (meaning you couldn't do `.c-button--large`).

Obviously this is a fairly basic example, but with more chaining comes more levels of specificity which makes for increasingly difficult changes and worse productivity.

I've done a fair amount of CSS in my time and I have felt the pain, I understand why BEM wants to keep specificity at 1.

One thing bothers me though. Isn't this very WET? You have to repeat the `.primary` rules in every `--primary` thing?

I'm still torn apart about `.button.primary` and `.button--primary`. Also semantic classes vs style bound classes. I'm not completely convinced by any methology.

I don't get your example.

What's the difference between

    .c-button.primary { … }
    .c-button.large { … }

and

    .c-button--primary { … }
    .c-button--large { … }
?

.c-button--primary has lower specificity that .c-button.primary

But .c-button.large has the same specificity as .c-button.primary.

Indeed, but with BEM, you keep a specificity of 1, which means you can override styles simply by adding a class and ensuring that it is further down in the style sheet than its other base classes.

Like mentioned above, this keeps things simple and prevents the snowball effect of people continually adding classes or selectors to override styles.

Single Reaponsibility principal. Create a class called .button. The responsibility of that class is to define what a button looks like. Then create a class called .button--primary whose sole responsibility is to define what a primary button looks like. If you create a class called .primary it has multiple responsibilities spread over the solution making it harder to maintain and improve upon

BEM basically gets rid of combination of classes because some people feel as though it is very difficult to locate every location of a class in css. So if you typically only define styles for any element once(or once for every font, color etc section) you are less likely to have unexpected changes. A lot of times it happens in reverse.

  <section class="frogs">
    <h1 class="headline frogs__headline">Frogs</h1>
  </section>

  <section class="frogs">
    <h1 class="headline">Frogs</h1>
  </section>

So in the second one some sadness happening possibilities of a developer being a jerk:

1. Removes the "frogs" class from section. Now the baseline headline applies to the h1

2. Buries this joy somewhere

  .frogs h1 { sadness: here; }

3. Wraps the h1 in a div or something clever for some effect or whatever

  <section class="frogs">
    <div class="sweet-slider-plugin">
      <h1 class="headline">Frogs</h1>
      ...
    </div>
  </section>

and someone wrote the rule as

  .frogs > .headline

because further down in the section someone else used the .headline class nested in a "frog of the day" sub section.

I'm definitely not trying to say BEM is what you have to use. Or if it is good or bad. Just trying to explain that there is an actual point to it.

That's called the BEM naming convention. BEM stands for block, element, modifier. You can read about the reasoning for it in places like this one: http://csswizardry.com/2013/01/mindbemding-getting-your-head...

I know BEM and was asking for reasons why there are no global modifiers for things that make sense on every block or element (e.g.: importance, size, state) other than "that's not BEM".

Yes, frontend layout designers reinvented Hungarian notation. It'll take another 10 years to realize it's not a very good idea.

If I am not mistaken, the Hungarian notation part in Blaze (o-…, c-…, …) is not needed for BEM. Just a prefix to distinguish different kinds of blocks.

I think you're missing the whole point of BEM. Your suggestion is something I would avoid at all cost.

Here's a good article explaining the idea:

http://csswizardry.com/2013/01/mindbemding-getting-your-head...

I think you would avoid defining .primary I don't see a reason, why you would not define .block__element.primary.

> I think you would avoid defining .primary

How would you enforce that when working in a big project with many contributors? I don't want to risk breaking my component if someone all of a sudden declares a global .primary class. When using --primary I know that won't happen since it's completely bound to my component.

> How would you enforce that when working in a big project with many contributors?

So what you're saying is that BEM is the Java of CSS? Because that explains a lot.

Reply on news.ycombinator.com