

The single responsibility principle applied to CSS - Brajeshwar
http://csswizardry.com/2012/04/the-single-responsibility-principle-applied-to-css/

======
roryokane
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.

~~~
reissbaker
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. :)

~~~
Schlaefer
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...](http://sass-
lang.com/docs/yardoc/file.SASS_REFERENCE.html#extend)

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

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

------
ckluis
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).

------
aymeric
This is one thing the zurb Foundation framework does well:

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

~~~
ricardobeat
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.

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

~~~
dazbradbury
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.

~~~
bashzor
> 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.)

