- Less HTML clutter (caused by all those fragmented class names).
<button class="btn btn-primary btn-large btn-outline">Buy!</button>
- Descriptive classes (or no classes at all) in the HTML results in cleaner and easier to read HTML.
<button class="btn-call-to-action">Buy!</button>
- Easier to determine the look of the element by reading the
@include
name instead of deriving the info from all the individual properties.
@mixin button-style-ghost {
display: inline-block;
padding: .5rem;
border: 2px solid #333;
color: #333;
font-weight:bold;
background: transparent;
}
-
Make dependencies visible by moving the patterns to separate files and only
@import
them when required. -
Use composition to build complex patterns by combining simple ones.
@mixin box-float {
@include box-rounded;
@include box-padded;
background: #fff;
box-shadow: 0 .25rem .5rem rgba(0,0,0,.25);
}
-
Keep style complexity in your CSS instead of your HTML, no need to edit the HTML when changing looks.
-
Impact of duplication in generated CSS is minimized by gzip. Also Mixins vs. Extends.
-
When old style patterns are no longer referenced they automatically stop taking up space in the CSS output.
-
The use of descriptive classes in your HTML instead of OO classes can work to enforce a more concise style. Having to name each element helps in determining if there might be too many similarly looking elements being used to achieve the same UX goal (10 different call to action button styles).
There are positives and negatives to this approach. With pure OOCSS the goal is to have small, granular classes that can be applied across multiple elements. If you want to change the appearance of an element, you add/remove classes from it (read: edit html). With this approach, if you want to change the look of an element, you add/remove mixins from the selector (read: edit sass).
Another issue with this approach is that you have to create a new selector each time you want a slightly different style on an element and add the mixins to it, rather than simply adding the classes you need to your html. For example:
If you wanted a box that had blue text instead, using OOCSS you'd just add the
text-blue
class in place of thetext-red
class on the element, but with you're approach you'd need some version ofThere's the argument of file size (more classes in html vs more selectors in css) but I've yet to read of a real-world example where that was a true factor in page load times.
Your approach does have the benefit that is inherent to css in general, one change in the stylesheet propagates to all elements with that selector. This means if you wanted all the
.my-box
's to have a smaller padding, you'd only have to make a change in one spot and it'd propagate to all.my-box
's vs. going through all the html and changing the classes applied to the boxed elements. Many articles have discussed at length the pros/cons to this behavior. Overall, this is not a bad way to go by any means, it's just not the be-all end-all that everyone is searching for in CSS.