Trouble naming children of BEM modifiers

Question

So I have the following BEM classes:

.block
.block--modified
.block__child

Now from what I have seen most people would name the child of the modified .block like so:

.block--modified__child

Which I get that makes sense, but is there a reason you could not name it like this:

.block__child--modified

I think this looks better and keeps the modification more isolated / explicit, I also like this because then you can have multiple modified children that are not dependant on the parent being modified i.e

We can have a .block and .block .block--modified elements.

And both can have .block__child and .block__child--modified which still follows the naming convention but makes the child elements (modified or not) more flexible.

For a better example say I have the following classes:

.alert
.alert--warning
.alert--urgent

.alert__call-to-action
.alert__call-to-action--warning

And I want to layout my HTML as follows:

<div class="alert">
    <button class="alert__call-to-action">
        Action! (No Modifier)
    </button>
</div>

<div class="alert alert-warning">
    <button class="alert__call-to-action alert__call-to-action--warning">
        Action! (Warning Modifier)
    </button>
</div>

<div class="alert alert-urgent">
    <button class="alert__call-to-action alert__call-to-action--warning">
        Action! (Warning Modifier)
    </button>
</div>

So you will see I want to re-use the .alert__call-to-action--warning modifier twice in the .alert--warning and .alert--urgent because for what ever reason the styling is the same. Does this make sense from what I can see it makes the modifiers much more usable?

Is there a reason we don't do this? Sorry if there is a better place to post about this please let me know.

This question is either too broad, opinion based or requires discussion and so is off-topic for Stack Overflow. If you have a specific, answerable, programming issue, please provide full details. — Paulie_D, Mar 10 '16 at 10:10

score 5 · Accepted Answer · answered Mar 10 '16 at 11:48

5

Actually BEM methodology says you shouldn't reflect block modifiers in elements naming. Use nesting for such occasions.

See second paragraph of https://en.bem.info/faq/#why-should-i-avoid-using-nested-selectors

That's important because:

There can be quite a lot of modifiers on same block/element
Modifiers represent state of a block/element which may be changed in runtime with JS.

So if you go with modifiers reflected in elements naming it'd be much harder to handle.

answered Mar 10 '16 at 11:48

tadatuta

2,007
11
12

Thanks I understand the the principle of avoiding nesting sorry I was not actually asking about nested CSS so much as class names. In all the demonstrations of BEM I have seen people user `.block--modified__child` why is this preferable to this `.block__child--modified`? – Otis Wright Mar 10 '16 at 20:00
I was not quite clear in my answer, I think, but this is just the case where nesting IS better! – tadatuta Mar 10 '16 at 22:13
Ah-hah! Now I see what you mean, that's really interesting thank you makes sense now. – Otis Wright Mar 10 '16 at 22:30
An example would be nice. By nesting do you mean something like `.par--modifier .par__sub`? – hugo der hungrige Apr 17 '19 at 09:09

score -1 · Answer 2 · answered May 09 '16 at 15:29

Which I get that makes sense, but is there a reason you could not name it like this:
.block__child--modified

Yes, the modifier needs to be attached to what it modifies.

If you've got a state for a block, you attach the modifier to the block:

.message--warning

If you've got a state for an element, you attach the modifier to the element:

.widget__content--expanded

If you attempt to mix the two the meaning gets lost:

//this is a message that is in the warning state
.message--warning

//this is a heading of a message. The heading is in the warning state
.message__heading--warning

So you will see I want to reuse the .alert__call-to-action--warning modifier twice in the .alert--warning and .alert--urgent because for whatever reason the styling is the same.

Don't mix and match modifiers

Does this make sense from what I can see it makes the modifiers much more usable?

You may be able to save some bytes of CSS with this invalid BEM usage, but this sort of micro-optimization has never been the goal of BEM.

It seems to me what you have is not a set of blocks with modifiers. What it looks like you have are a series of blocks that inherit from a similar base block.

Raw CSS doesn't allow for this sort of inheritance to be made explicit, which is unfortunate. Using a preprocessor does though. I will use LESS in this example.

Instead of defining .alert, .alert--warning, and .alert--urgent, consider making three separate blocks:

_alert.less

.alert {
  ..default styles..

  &__call-to-action {
    ..default styles..
  }
}

_warning.less

@import (reference) 'alert';
.warning {
  .alert;

  ..override styles..

  &__call-to-action {
    ..override styles..
  }
}

_urgent.less

@import (reference) 'warning';
.urgent {
  .warning;

  ..override styles..

  &__call-to-action {
    ..override styles..
  }
}

Note that urgent is a warning, and warning is an alert. Defining your classes like this allow you to use descriptive names in your HTML:

<div class="warning">
  <button class="warning__call-to-action" ...>...</button>
</div>

and allow you to get the most out of your styles, because you only have to override the few properties that change.

Of course, this entire example relies on being able to use a preprocessor to reduce the amount of CSS you write. Writing raw CSS is much more verbose.

Trouble naming children of BEM modifiers

2 Answers2