Hi, @moymadethis!

You are right, nesting should be avoided wherever possible but still can be quite useful when inner parts of block should be styled by parent modifier. See https://en.bem.info/faq/#why-should-i-avoid-using-nested-selectors for some examples.

<div class="band band--dark masthead"> is absolutely fine. It's called mixes in BEM. See https://en.bem.info/method/key-concepts/#mix

Thanks, that's great.

I have another question, not really related but I don't want to pollute the forum with loads of my little queries!

My default button styling is done using a class of .btn, using BEM I'll specify different button styling using btn btn--dark. I guess if a button has a unique graphic/icon on it (Shopping cart for example) I would use the class btn btn--basket? Or would a class of btn-basket be more appropriate?

In the code below, I have a series of buttons which are included in a listing for a product:

<div class="product">
    <div class="product__item product__item--options">
        <a href="#" title="TITLE TEXT" class="product__btn product__btn--share">Share</a>
        <a href="#" title="TITLE TEXT" class="product__btn product__btn--favourite">Add to favourites</a>
        <form class="product__form">
            <button class="product__btn product__btn--basket">Add to Basket</button>
        </form>
    </div>
</div>

These buttons have no text and are square icon based buttons, so I've not used the btn class. As each button has a totally different icon, would it be better to use a class of product__share instead of product__btn--share - or do you think the above is acceptable? I suppose the same could able to list-items where unique classes are needed for styling.

There are actually 5-6 buttons in totally, I've just truncated the code for this example. There are also more product__item elements, hence the product__item--options class - maybe I'd be better using product__options on that too?

Thanks again!

I don't want to pollute the forum with loads of my little queries

Feel free to do so ;)

These buttons have no text and are square icon based buttons, so I've not used the btn class

You may consider using universal icon block with proper modifiers for each icon. And reuse it everywhere (inside btn as well). Don't be afraid of extra DOM nodes or classes — they all will be gziped well.

That sounds like an idea, so something separate from the btn class. I use some icon fonts, so maybe btn-icon might work better? Then modifiers would be btn-icon btn-icon--basket, btn-icon btn-icon--delete, btn-icon btn-icon--close for example?

When you modify and element, should the children be modified as well or is that a bit over the top? It seems like this is where nesting is perfectly fine?

For example on this pagination it would be unnecessary to add a class of pag__link--inactive onto the anchor?

<ul class="pag">
    <li class="pag__item pag__item--prev inactive"><a href="#" class="pag__link" title="TITLE TEXT">Prev</a></li>
    <li class="pag__item current"><a href="#" class="pag__link" title="TITLE TEXT">1</a></li>
    <li class="pag__item"><a href="#" class="pag__link" title="TITLE TEXT">2</a></li>
    <li class="pag__item"><a href="#" class="pag__link" title="TITLE TEXT">3</a></li>
    <li class="pag__item pag__item--next"><a href="#" class="pag__link" title="TITLE TEXT">Next</a></li>
</ul>

Also, if SCSS is used, I dunno if it would be better to write this nested like this:

.pag__link {

    &:hover {
        background: $pagbackground;
        color: $white;
    }

    .current &,
    .inactive & {
        background: $linkhover;
    }
}

The issue being I guess the parent current / inactive has to attachment to the pag__item when it's converted to CSS. Unlike .pag__item.current {} / .pag__item.inactive {} ?

Thanks again!

I use some icon fonts, so maybe btn-icon might work better?

It's just fine but in the future you may also need an icon somewhere else not only inside a button. So it's also possible to create icon block beforehand and use it as <a class="btn icon icon--close">. Which gives you possibility to keep button styles separate from styles about icons but still apply them on the same DOM node.

When you modify and element, should the children be modified as well or is that a bit over the top? It seems like this is where nesting is perfectly fine?

You are right, nesting is just ok for such cases. But shouldn't it be pag__item pag__item--current instead of just pag__item current as current looks just like a modifier of an item (and same for inactive)?

if SCSS is used, I dunno if it would be better to write this nested

I'd sacrifice brevity for obviousness and keep parent first (children shouldn't know about parent but for parent it's ok to know about children):

.pag__item {
    &--current .pag__link,
    &--inactive .pag__link {
        background: $linkhover;
    }
}

.pag__link {
    &:hover {
        background: $pagbackground;
        color: $white;
    }
}

I used fontello to create @font-face, so when I add a class of icon-tick, icon-mail, icon-trash etc and icon is applied to the pseudo :before class and displayed alongside the element. Primarily I use this on headings, lists and buttons when text is also visible alongside the icon.

The icons I originally mentioned would be square buttons without any text and applied via a background-image rather than the icon font method. So I don't know if the icon class would clash with this (I suppose there's no --, so they would be deemed separate).

I'm not sure if this is right but I'm always a bit cautious using icon fonts on important form elements or elements that are vital to the functionality of the page - maybe I shouldn't be. But I always worry that if the icon isn't displayed in a certain browser and there's no text visible the user has no idea what the button does. So a background image always seemed like a safer approach? As no text would be visible, I guess the only thing the icon would need to inherit from a btn would be the background-color and maybe the height. Also as the background-image they 'icons' would use is a sprite, so I don't think they'd ever be applied to an item with a flexible width, incase another part of the sprite became visible.

You are right, nesting is just ok for such cases. But shouldn't it be pagitem pagitem--current instead of just pag__item current as current looks just like a modifier of an item (and same for inactive)?

I thought that too and actually used pag__item--current and pag__item--inactive to begin with. Then I thought of them more as 'states', so decided to simplify it. This is probably breaking the rules though and for consistency it's probably best to use the method you mentioned. I guess this would be suitable for nav__item--has-dropdown as well?

Then I thought of them more as 'states'

Modifiers are applied to states as well.

I guess this would be suitable for nav__item--has-dropdown as well?

Yes, sure.