5 ms·

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. W

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 { … }

ryantownsend 10y ago
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.
- allendoerfer 10y ago
  I don't get your example. What's the difference between .c-button.primary { … } .c-button.large { … } and .c-button--primary { … } .c-button--large { … } ?
  - nilliams 10y ago
    .c-button--primary has lower specificity that .c-button.primary
    - allendoerfer 10y ago
      But .c-button.large has the same specificity as .c-button.primary.
      - deleted 10y ago
        [deleted]
      - buchanaf 10y ago
        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.
        grumpywizards 10y ago
        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
- kolme 10y ago
  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.
Flimm 10y ago
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-round-bem-syntax/ http://csswizardry.com/2013/01/mindbemding-getting-your-head...
- allendoerfer 10y ago
  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".
Kiro 10y ago
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-round-bem-syntax/ http://csswizardry.com/2013/01/mindbemding-getting-your-head...
- allendoerfer 10y ago
  I think you would avoid defining .primary I don't see a reason, why you would not define .block__element.primary.
  - Kiro 10y ago
    > 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.
    - throwanem 10y ago
      > 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.
ungzd 10y ago
Yes, frontend layout designers reinvented Hungarian notation. It'll take another 10 years to realize it's not a very good idea.
- allendoerfer 10y ago
  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.
hiou 10y ago
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> or <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.

ryantownsend 10y ago

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.

allendoerfer 10y ago
I don't get your example. What's the difference between .c-button.primary { … } .c-button.large { … } and .c-button--primary { … } .c-button--large { … } ?
- nilliams 10y ago
  .c-button--primary has lower specificity that .c-button.primary
  - allendoerfer 10y ago
    But .c-button.large has the same specificity as .c-button.primary.
    - deleted 10y ago
      [deleted]
    - buchanaf 10y ago
      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.
      - grumpywizards 10y ago
        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
kolme 10y ago
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.

Flimm 10y ago

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-round-bem-syntax/ http://csswizardry.com/2013/01/mindbemding-getting-your-head...

allendoerfer 10y ago
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".

Kiro 10y ago

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-round-bem-syntax/ http://csswizardry.com/2013/01/mindbemding-getting-your-head...

allendoerfer 10y ago
I think you would avoid defining .primary I don't see a reason, why you would not define .block__element.primary.
- Kiro 10y ago
  > 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.
  - throwanem 10y ago
    > 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.

ungzd 10y ago

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

allendoerfer 10y ago
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.

hiou 10y ago

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> or <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.