Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Reading SASS basic features on their website, I stumbled upon the @extend feature.

The example they give is the following:

.message {
    border: 1px solid #ccc;
    padding: 10px;
    color: #333;
}

.success {
    @extend .message;
    border-color: green;
}

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

.warning {
    @extend .message;
    border-color: yellow;
}

That compiles to

.message, .success, .error, .warning {
    border: 1px solid #cccccc;
    padding: 10px;
    color: #333;
}

.success {
    border-color: green;
}

.error {
    border-color: red;
}

.warning {
    border-color: yellow;
}

Thus with this snippet of HTML

<div class="success">hello world</div>

you style your element with properties of .message and .success. However I feel this way of writing HTML (and CSS) very poor, in terms of semantic (you don't explicitly see from the markup above that the element has also the styling of .message).

Shouldn't the snippet above be

<div class="message success">hello world</div>

?

I feel it to be more descriptive, and more easily reusable. For example I could assign the .success class (as written in the above CSS but without the @extend) to other elements which are not messages, and so using the class as a modifier, in a BEM-fashion.

So my question is, is the SASS example approach more desiderable than mine?

share|improve this question

1 Answer 1

up vote 3 down vote accepted

Both approaches are valuable and semantically, they are not very different. Remember that you also can use both in Sass.

I believe that what makes you think that yours is more descriptive is their choice of class names: success class is not descriptive enough: how would anyone guess that success refers to a message, and not, say, a small green check icon on the side of an item showing whether a unit test passed? If we chose a (meaningless) example with better names, things become clearer:

.animal { ... }
.cat { @extend .animal; ... }
.dog { @extend .animal; ... }

Would you rather write:

<div class="animal cat">...</div>

or:

<div class="cat">...</div>

Probably the second variant, since it avoids redundancy and makes your HTML more readable.

If you know object oriented programming, think of:

  • Their approach as inheritance: Cat class inherits Animal, and can have only zero or one base classes.

  • Your approach as interfaces: ISuccessful interface can be implemented by both Message class and TestResult; at the same time, Message can implement at the same time ISuccessful, IImportant and IMandatory.

share|improve this answer
    
Yes, there are cases where the "single class" approach isn't worse, or is even better as the one you reported, but in CSS I saw more often the other case, hence my question. –  mattecapu Aug 3 '14 at 13:05
    
I see only now your edit, that's a very good point. But isn't the interface approach more broadly used as it permits to add functionalities more easily? (I'm actually quite ignorant in this field, so I'm not really trying to protect my position) –  mattecapu Aug 3 '14 at 13:08
1  
@mattecapu: from my experience, your approach is used indeed more frequently in CSS. –  MainMa Aug 3 '14 at 13:13
    
@mattecapu It's probably more frequent because it's more flexible. With the "clearer" animal-based example, if you have interactivity with javascript, you'll either have to select all types of animals or go back and add the animal class to the elements. It also distinguishes between ambiguities in English - for example, is it "bat" or "bat"? –  Izkata Aug 3 '14 at 23:54
    
@Izkata yes these are other benefits of that kind of approach, I didn't think about it –  mattecapu Aug 4 '14 at 8:45

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.