<h3 id="the-path-to-bloat">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:

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

Compare this to the traditional way:

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

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. :