When it comes to CSS, I believe that the sacred principle of “separation of concerns” (SoC) has lead us to accept bloat, obsolescence, redundancy, poor caching and more. Now, I’m convinced that the only way to improve how we author style sheets is by moving away from this principle.

The Path To Bloat

Because the styles of our module are tied only to presentational class names, they can be anything we want them to be. For example, if we need to create a simple two-column layout, all we need to do is replace the link with a div in our template. That would look like this:

<div class="Bfc M-10"><div class="Fl-start Mend-10 W-25">column 1</div><div class="Bfc">column 2</div>
</div>

And we would need only one extra rule in the style sheet:

.Bfc {overflow: hidden;zoom: 1;
}
.M-10 {margin: 10px;
}
.Fl-start {float: left;
}
.Mend-10 {margin-right: 10px;
}
.Fz-s {font-size: smaller;
}
.W-50 {width: 50%;
}

Compare this to the traditional way:

<div class="wrapper"><div class="sidebar">column 1</div><div class="content">sidebar</div>
</div>

This would require us to create three new classes, to add an extra rule and to group selectors.

.wrapper,
.content,
.media,
.bd {overflow: hidden;_overflow: visible;zoom: 1;
}
.sidebar {width: 50%;
}
.sidebar,
.media .img {float: left;margin-right: 10px;
}
.media .img img {display: block;
}

I think the code above pretty well demonstrates the price we pay for following the SoC principle. In my experience, all it does is grow style sheets.

Moreover, the larger the files, the more complex the rules and selectors become. And then no one would dare edit the existing rules:

• We leave alone rules that we suspect to be obsolete for fear of breaking something.
• We create new rules, rather than modify existing ones, because we are not sure the latter is 100% safe.

In other words, we make things worse because we can get away with bloat.

Nowadays, people are accustomed to very large style sheets, and many authors think they come with the territory. Rather than fighting bloat, they use tools (i.e. preprocessors) to help them deal with it. Chris Eppstein tells us:

"LinkedIn has over 1,100 Sass files (230k lines of SCSS) and over 90 web developers writing Sass every day."