You MUST use @extend when working with module to inherit from the base element

[BenjaminRCooper]

Using @extend will allow you to remove the bloat which may exist within your class attribute contained in your module's markup.

Because, as a team we work using BEM notation, a modifier or child element are prefixed with the base class, so for readability purposes within your Markup, there is no need to contain both the base element and the modifier within the class attribute.

Example:

.site-message {
     color: white;
     font-size: 1.4rem;
}

.site-message--error {
     @extend .site-message;
     background-color: red;
}

With regards to file size, this is not so much of an issue, as GZIP will take care of any duplication contained within your partials.

Note: This also applies to utility and helper methods too.

[jonspark]

Interested as to why this route? Personally I've been running a

.site-message {
    color: white;
    font-size: 1.4rem;

    &.site-message--error {
        background-color: red;
    }
}

style of approach.

[BenjaminRCooper]

Isnt that an unnecessary increase on specificity though?

B

[jonspark]

I don't know... I've never come across a time when I've needed a .site-message--error without a .site-message. Generally did it to save on repeated code, D-R-Y and all that...

[BenjaminRCooper]

But the above would result in the following;

.site-message.site-message--error {
      color: white;
      font-size: 1.4rem;
      background-color: red;
}

B

[jonspark]

Corrected the code example...

[BenjaminRCooper]

Jon, please explain. I'm so confused.

Why do you feel your approach is a more suited option?

B

[jonspark]

I'm not really trumping my method, it's a genuine question... I don't like repetition. @extend is a double-declaration and produces:

.site-message {
     color: white;
     font-size: 1.4rem;
}

.site-message--error {
     color: white;
     font-size: 1.4rem;
     background-color: red;
}

I've been using the quoted code, mainly as it encapsulates the whole block in indented braces and keeps everything in a module together. The more specific selector doesn't do any harm (or does it?).

As a modifier class has a distinct name, why extend at all? (Not rhetorical, discuss)

.site-message {
     color: white;
     font-size: 1.4rem;
}

.site-message--error {
     background-color: red;
}

[lewismorris]

Hey @jonspark ,

@extend would produce the following using @Passenger-Inspired example

.site-message, .site-message--error {
  color: white;
  font-size: 1.4rem;
}

.site-message--error {
  background-color: red;
}

I think this may be where the confusion is coming from.

Lewis

[BenjaminRCooper]

The option you include @jonspark will not inherit the properties set on the base class as required.

If you run your option through a Sass compiler, you get the following;

.site-message {
  color: white;
  font-size: 1.4rem;
}
.site-message.site-message--error {
  background-color: red;
}

This doesn't achieve the required result with regards to our BEM approach.

B

[jonspark]

This doesn't achieve the required result with regards to our BEM approach.

So what is the result we're trying to achieve cos I think I missed the memo...

[BenjaminRCooper]

Well if site-message--error is a modifier of the site-message base block, how is the modifier receiving the base styles from the base block?

If you look at your implementation, site-message--error is only receiving one style, and not the styles from the base element.

B

[lewismorris]

I know the aim of your example @Passenger-Inspired is to stop bloat of the class attribute, but logically wouldn't it make more sense to have:

<div class="site-message site-message--error"></div>

That way i can instantly see it's the site message module with the error helper?

Little article on using more classes in HTML from Harry Roberts which is a good read - http://csswizardry.com/2012/10/a-classless-class-on-using-more-classes-in-your-html/

[BenjaminRCooper]

Actually sorry @jonspark, now see what you're saying.

Will speak when you come in the office, it will be easier.

B

[BenjaminRCooper]

Closed, as I have spoken with @jonspark seperately

[BenjaminRCooper]

Implemented

[BenjaminRCooper]

Needs to be changed slightly to specify you should only extend placeholder elements, and the fact it may not need to be a MUST

[BenjaminRCooper]

Two things with this. I propose we only use @extend on placeholders. The idea is that when you create a utility or module which you would like to be extendable, you create both a placeholder and class for that item to allow for it to be referenced in your markup, as well as being extended as a placeholder.

Thoughts on it being a MUST? I think it should be due to trying to enforce a coding style, but open to other ideas.

[lewismorris]

I think this sounds like a good idea going forward as we've seen the mess that using @extend on classes can cause, when used incorrectly.

I've not got any issues with going with a MUST for this as i tend to stay away from using the @extend selector where i can.

[BenjaminRCooper]

Still requires sign off from @matchboxhero, so will wait to add.

Ben