The single responsibility principle applied to CSS | Hacker News Reader

The single responsibility principle applied to CSS

csswizardry.com

24 pointsBrajeshwar11 comments

The article uses normal CSS, but you can apply the same principle in Sass/Less/Stylus, and in an even cleaner way. For instance, here is an example from the article, abbreviated and converted to Sass. You can refactor

  .header
    padding: 20px
    margin-bottom: 20px
    background-color: #121416
    color: #fff

  .content
    width: 640px
    float: left
    margin-right: 20px
    padding: 20px
    margin-bottom: 20px

into

  @mixin island
    display: block
    padding: 20px
    margin-bottom: 20px

  .header
    @include island
    background-color: #121416
    color: #fff

  .content
    @include island
    width: 640px
    float: left
    margin-right: 20px

, and you don't even have to change the HTML.

The Sass mixin example is clean, but you'll end up generating much larger files that way: the preprocessor will repeat the island definition for every single class you mix it into, which means that the more useful and reusable your mixin actually is, the more the output will get bloated. The following CSS:

    .island {
      display: block;
      padding: 20px;
      margin-bottom: 20px;
    }

    .header {
      background-color: #121416;
      color: #fff;
    }

    .content {
      width: 640px;
      float: left;
      margin-right: 20px;
    }

Is roughly as clean, but will make your files much smaller by virtue of not repeating the definitions per class. In general, avoiding property mixins (aside from vendor prefixes) and deep nesting in compile-to-CSS languages helps keep your output small and your pages fast. :)

The Sass code should use @extend [1] instead of @mixin, which doesn't insert the whole definition each time but extends the base definition:

    .island, .header, .content { display block; … }

[1]: http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#ex...

By following this principle you're moving presentation rules to the HTML. Taken to it's extreme this would mean

    .red { color:red; }

These techniques became relevant because they make your CSS leaner, speed up development and result in more maintainable code. But compression + high bandwidth along with systems like LESS/SASS make this effort moot: you can have the same benefits while still keeping most of presentation separate from content.

I think this technique may render CSS compilers (sass, etc.) largely unnecessary. Their main advantages are variables and arithmetic. The use of factored out mixin-type classes does a good part of what variables do for you. And one of the chief reasons that we need to do arithmetic in CSS is the weird box model, where padding adds to the width of a div. Use "box-sizing: border-box;" and this problem goes away.

My preferred approach. I define button style 1,2,3,etc and then background 1,2,3 and am able to mix and match numerous buttons easily. This approach can be used very effectively with A/B testing by switching a single class (either background or button style).

This is one thing the zurb Foundation framework does well:

<a href="#" class="nice small radius blue button">Button Text</a>

Want to change the color? Edit the HTML (and CSS). Change the radius? Edit CSS. Remove the radius? HTML. Doesn't make much sense to me.

I always find it funny how people tell how to code great (like now, in CSS), and yet their website is totally messed up on my phone--the logo floating somewhere in the middle of the text and scrolling while I scroll. So much for good code.

Cross-browser compatibility is often the reason "good code" turns into messy code!

You develop in one browser, and then make adjustments to it to make sure it works in all major / mobile browsers. This step often introduces some dubious workarounds and mess because it can be such a painful process.

That isn't to say one shouldn't try to write re-usable and maintainable code in the first place. But I also agree with your more general point (just not in css), that neat/maintainable code != correct code.

> Cross-browser compatibility is often the reason "good code" turns into messy code!

I think that too depends on how you code it. You can code mechanics, or you can code logic (quoting an earlier blogpost title which was also on HN).

  var hr = new httprequest(); //Where the httprequest function is defined elsewhere

versus 10 lines of code right here to support all browsers since IE5 or so. This might be even more readable as when you'd only write it for one browser.

(I couldn't think of a similar example in css.)

Reply on news.ycombinator.com