DRY CSS: Don’t Repeat Your CSS

Posted: 16 Apr 2012 05:30 AM PDT

A few weeks ago in the comments on my post about css formatting, Brett and David pointed me to a couple of articles and a presentation I hadn’t yet seen. All had interesting ideas about css practices and I thought I would offer some of my thoughts on them.

One of the articles, Don't use IDs in CSS selectors?, makes the argument for using classes over IDs as css styling hooks. Since I covered another article with similar of arguments I won’t cover Oli’s article here, but would recommend you give it a read.

In this post I want to talk about a presentation Brett pointed me to. I’ll get to the article David pointed me to next week. The presentation is one give by Jeremy Clarke on the topic of DRY CSS.

DRY CSS Principles

I wasn’t quite sure what to make of Jeremy’s presentation. I’ve seen some of his other presentations and generally like both Jeremy and his ideas. He’s certainly worth listening to. While I agree with the basic principle of don’t repeat yourself, I found myself unsure of the methods set out in the presentation and if they really solved the problem we’re trying to solve.

Some of my doubt is probably due to a lack of practical application on my part so keep that in mind. Let me walk you through Jeremy’s DRY ideas and then point out what I did and didn’t like about them.

If you’re not familiar with DRY, it stands for don’t repeat yourself, which is hopefully something we can all get behind. It’s why we want variables and functions. Many are moving to css preprocessors for this reason though Jeremy doesn’t seem to care for them He suggests they lead to destandardization and dependence on external libraries. I’m not sure either is really true.

Jeremy offered 2 principles for writing good css.

Keep style separate from content
Avoid specificity by harnessing the cascade

These should look familiar as they’re essentially the same principles of OOCSS and SMACSS. However Jeremy sees IDs and classes a little differently. He thinks IDs are fine for styling hooks and that both should be named based on the content as opposed to how the content looks.

This goes against what Oli says in the article linked to above and the one I covered a couple weeks back by Nocolas Gallagher, both of whom say it’s fine and preferred to name classes after how an object looks and suggest we skip using IDs for styling hooks

So how does it work?

How DRY CSS Works

DRY CSS comes down to 3 things:

Group reusable css properties together
Name these groups logically
Add your selectors to the various css groups

Each group should be defined by shared properties. For example one group might describe the background color and border color for a content box used throughout your design while another might describe a consistent set of type characteristics used throughout your design.

Each property/value pair should be defined only once, though in his code examples Jeremy does repeat pairs. Each group would also get multiple selectors. I think this makes more sense with an example and here’s one Jeremy used in his presentation.

Group reusable properties — Below we’re simply grouping a couple of background and border colors that would be used in a number of places across the site.

 {   background-color: #fff;   border-color: #ccc; } {   background-color: #fff;   border-color: #bbb; }

Name groups logically — I’m not sure these are great names and Jeremy was quick to point out they could be better, but hopefully you get the idea.

 #LIGHT-WHITE-BACKGROUND, .light-white-background {   background-color: #fff;   border-color: #ccc; } #MEDIUM-WHITE-BACKGROUND, .medium-white-background {   background-color: #fff;   border-color: #bbb; }

The all caps ID is to make this block of code easier to find in Firebug, which doesn’t show comments. The lower case class at the end is to enclose the selectors that will later be in between and to make it less likely you forget the commas at the end of all but the last selector rule. I wasn’t crazy about creating extra IDs and classes that really exist for a lone developer tool. I’d prefer comments above and below the group.

Add selectors to various groups — With groups defined and named, you add all the selectors that need to be displayed with the property/values of the group.

 #LIGHT-WHITE-BACKGROUND, .translation, .entry .wp-caption, #full-article .entry img, .recent-comment .comment-text, .roundup h3, .post-header-sharing, #post-categories td.label, #post-archive roundup h3, .subscription-manager ol, .light-white-background {   background-color: #fff;   border-color: #ccc; } #MEDIUM-WHITE-BACKGROUND, textarea:focus, input:focus, #author-email-form .input-focus, #respond p input:focus, .wpfc7 input:focus, .medium-white-background {   background-color: #fff;   border-color: #bbb; }

The above is a simplistic example for the sake of demonstration. The general idea is to think in terms of style patterns. You have a box in your design that holds content. You write the styles necessary to create it visually and place them together in a group. You give the group a name, and then add the css selectors that will visually be displayed using the pattern.

One of the questions I immediately had was would all these selectors really be needed? What advantage does this offer over having each group be a class that’s added where needed in the html. Sure it would reduce the need for classes, but is that a bad thing?

I’ve mentioned a few times in recent posts that it’s really about coupling and have pointed to some articles showing how a class couples css and html less than the descendent selectors that are being used here.

Additional Thoughts

Throughout the presentation Jeremy mentions some of the benefits of his DRY approach. Here are a few of them along with some of my thoughts

It encourages you to think in terms of style patterns (groups) rather than individual objects. I agree. I think this is a good goal and is also encouraged by OOCSS and SMACSS

The naming of groups encourages rational organization of design. I’m not sure about this. The examples didn’t feel all that organized to me with so many selectors in each group. I think it would make it more difficult to find the selector you want.

It encourages optimization and generalization of selectors. Again good goals and I think DRY CSS would help accomplish this.

It doesn’t require changes to html. True to an extent, but is this really more beneficial? I no longer thing so, though I know many do.

There shouldn’t be any performance issues. I think we’d be dealing with whatever performance issues we deal with now as part of using descendent selectors. I think jeremy quickly glossed over any potential downside here, though I don’t know that css selector performance is something most of us need to be overly concerned with.

DRY and OOCSS

Jeremy tried to show how DRY and OOCSS were compatible. He points out that the basic principles of both are mostly the same and that you can group styles in a way that adheres to OOCSS ideas. I’m not so sure this is true as the use of decedent selectors goes against OOCSS. Essentially DRY is replacing a single class with a variety of descendent selectors so as not to have to alter the html.

In the case of DRY when you want to change the style of a content box, you’d cut and paste it’s selector in the css from one group to another. In OOCSS you’d change a class name in the html. In either case you might need to define or redefine some styles.

Is one approach better than the other? To me using classes as in OOCSS seems a lot cleaner, easier to read, and more flexible. I’ve also become convinced that classes reduce coupling which is the real enemy here.

However if you’re someone who disagrees and thinks adding classes everywhere is the wrong approach you might want to give DRY CSS a look as it offers many of the same advantages of OOCSS in a different way.

Without having used either in practice to any great degree it’s hard for me to authoritatively state one approach is better than the other, though my sense is OOCSS is the better approach. Again I’m convinced that classes reduce coupling and are preferred. I also think OOCSS more readable.

presentations from Jeremy Clarke

Summary

Overall I think the basic ideas behind DRY CSS make sense. Don’t repeat yourself is a good general principle to follow and eliminating duplication of css code should naturally be part of that.

DRY CSS shouldn’t be too hard to understand if you followed the example code above. Create the groups, name them, and then add the selectors.

The main difference I can see between DRY and either OOCSS and SMACSS is that the first continues to use the same descendent selectors we’ve been using for years, while the latter two ask us to make greater use of classes. I think the class approach the better one and so I probably won’t be using DRY CSS in practice.

Not everyone agrees with the class approach though, and if you’re one of those people then I think you might enjoy DRY CSS. It aims trying to achieve the same basic goals of the class based approaches. I can certainly see the appeal of writing css this way.

Have you used DRY CSS? What to do you think? Do you prefer it to moving toward more class based css?