DRY CSS – Slides from my ConFoo 2012 talk

Posted by jeremyclarke on February 28, 2012 · design · GlobalVoices

Here’s the video with slides+audio of talk in case you prefer that. It’s 51min

This is an idea/talk that has literally been years in the making. Ever since I used this “DRY CSS” system for the Global Voices redesign I’ve been meaning to do the background research and lay it all out clearly like this. To me the core principle is so simple and standards-based that I have trouble believing it’s not already a thing, but I can’t find anyone else promoting it so here you go:

Embed should be above, here’s a direct link to the slideshare page: DRY CSS – A don’t-repeat-yourself methodology for creating efficient, unified and Scalable stylesheets »

Or if you prefer you can download the slides as a PDF »

Let me know what you think! Am I crazy? Why aren’t we already doing it this way?

Posted by jeremyclarke on · design · GlobalVoices


  1. tim

    You’re my favorite nerd.

    February 29th, 2012 at 12:05 am

  2. Renoir Boulanger

    I’ve been thinking the same Jeremy.

    Personnaly, I wrote my own system, then after creating the whole system, I discovered that somebody did it better.

    Better than my attempt, though.

    Many of the field did. actually. The best guidelines I found was @SnookCa’s SmaCSS.com book. I think that even the Twitter Bootstrap developers.

    We could talk about it soon I guess :)

    February 29th, 2012 at 2:52 am

  3. jeremyclarke

    I really enjoyed the SMACSS book and got a lot from it I think, if only in the “oh yeah, I do that sometimes and it’s awesome, I should do that all times” way. OOCSS also has a lot to say in terms of pattern building. DRY is just an alternative to LESS/SASS for code sorting.

    February 29th, 2012 at 9:00 am

  4. Alice

    Your DRY CSS method is pretty sound overall, but there are still things you have to repeat in plain CSS: the selectors themselves. As the site grows more complex, the lists of grouped selectors can get pretty daunting. Also it’s hard to understand exactly what styles applies to one particular selector (without doing a find in file, or looking at its styles in the browser debugger), and updating the style of one selector could involve a lot of work, modifying its group membership for each attribute that needs changing.

    I think Sass could still help with organization and DRYing up the styles in this case, so that it’s easier to see what groups are available, and which groups one selector belong to. You can have a clean list of groups in one place:
    .light-white-background {
    background: #fff;
    border-color: #ccc;
    .medium-white-background {
    background: #fff;
    border-color: #bbb;
    .small-text {
    font-size: 9px;
    .medium-text {
    font-size: 12px;

    Then use @extend to specify group membership:
    .header {
    @extend .light-white-background;
    @extend .medium-text;
    .footer {
    @extend .medium-white-background;
    @extend .small-text;

    Sass will compile the CSS so that each selector is put with its right groups:
    .light-white-background, .header {
    background: #fff;
    border-color: #ccc;
    .medium-white-background, .footer {
    background: #fff;
    border-color: #bbb;
    .small-text, .footer {
    font-size: 9px;
    .medium-text, .header {
    font-size: 12px;

    The end result is the same, but I think the Sass source code is even cleaner, more readable and easier to maintain. I got the idea from an article by Thomas Reynold, who uses this method to create a style guide in CSS, which is a similar concept: http://awardwinningfjords.com/2010/07/30/style-guides-using-sass-extend.html

    April 16th, 2012 at 5:43 pm

  5. jeremyclarke

    Alice I know exactly what you mean. At the conference where I presented this there were talks about both SASS and LESS and both were quite compelling. I think there’s definitely room to mix together DRY and SASS/LESS where DRY helps you think about your CSS and SASS/LESS helps you keep it even neater.

    One vital thing though is to use the @extend method (which stacks selectors) rather than @include (which repeats selectors), otherwise SASS/LESS are liable to give you the least-DRY CSS ever imagined. I was glad to hear that LESS is soon going to have the ‘extend’ type of include the way SASS does, removing what is right now a huge leg-up for SASS (personally I like LESS better in every other way).

    Ultimately DRY is only better if you value avoiding the LESS/SASS setup stack, although I think there is and will remain a market for pure-CSS solutions.

    Also use of “browser debugger” is core to this method. Before firebug/devtools I would never have used or recommended my system, but luckily we live in the present and not the dark ages of the past. As I like to say during talks: If firebug/devtools disappear I’ll just quit my job ;)

    April 16th, 2012 at 6:59 pm

  6. Alice

    Hi Jeremy, thanks for your thoughtful reply. I realized one more thing, which is that with the help of Less/Sass, it’d be easier to use DRY CSS with OOCSS if you want. Each OOCSS class just needs to @extend the right group rules. Is that similar to how you envision OOCSS using DRY CSS?

    I also have some other questions about DRY CSS.
    – How do you handle background images such as sprites?
    – A style property may be set for different reasons. e.g. both a login box and input fields inside a form could be float:left, but not for exactly the same reason. Would you create two group rules, both with float:left? Perhaps the example is contrived, but how do you distinguish the case where two selectors are related, or they just have the same property coincidentally?

    April 17th, 2012 at 1:52 pm

  7. jeremyclarke

    > Each OOCSS class just needs to @extend the right group rules. Is that similar to how you envision OOCSS using DRY CSS?

    I think I understand what you mean here and it sounds about right. I haven’t actually used OOCSS before so it’s hard for me to imagine. My main proposal is that you can take the theories behind OOCSS and apply them with DRY. I’m sure that would be easier with LESS.

    > How do you handle background images such as sprites?

    I haven’t experimented with that though I can imagine it would be pretty complicated. That said if you have sprite positions defined for specific classes or states then having a group for each sprite-position seems like it would work fairly well.

    > Would you create two group rules, both with float:left? Perhaps the example is contrived, but how do you distinguish the case where two selectors are related, or they just have the same property coincidentally?

    That’s a fundamental question underlying what I refer to in the talk as “group design” and ultimately it’s up to the coder. Personally I try to draw a hard line at two property:value pairs that go together as needing to be grouped, whereas a single property is less vital. My own CSS certainly doesn’t adhere dogmatically to any DRY principle, there are all kinds of exceptions (aside from colors, where I am diligent because it’s the most obvious place where everything should match).

    The real question is “Is this a pattern used throughout the site?”, if so then make it a group and put the other relevant selectors in there as well. If it’s not a pattern then you ask the follow up questions “Why isn’t this a pattern? Should this be a pattern? How can I standardize this?” Ideally that dialogue should push you toward an OO/SMACSS pool of re-usable objects that can easily be applied to different site components. In my own experience the answer to the second set of questions often turns out to be “this is too particular to bother with, I’ll save time by leaving it as an exception”, though in many other cases the answer is “oh yeah, this is just a silly variation of X group that already exists, I’ll add it there”.

    Thanks for the detailed comments. It’s interesting to hear from people who seem to have actually tried OOCSS, as most people I talk to have just heard about it and think it sounds good ;)

    April 17th, 2012 at 4:04 pm

  8. Alice

    Truth be told, I’m not familiar with OOCSS either, though I kind of get its general concept, which is to create reusable CSS modules using classes (seems like SMACSS might have a similar idea). My question was really to confirm the idea that these module classes should still conform to groups.

    As for sprites, I can imagine this to be an area where you don’t need to adhere to DRY as much, i.e. sprite classes could either be applied directly onto an element, or be used as groups.

    I also really appreciate your detailed response to my 2nd question! I guess doing styling for a big site inherently involves trying to make sense of a huge amount of complexity, so you can only hope that with good guiding principles as basis, you’ll make intelligent decisions.

    April 17th, 2012 at 8:40 pm

  9. Starkov Vladimir

    is it some kind of hardcoded classnames, describing visual appearance and not semantic value of element?

    April 19th, 2012 at 12:40 am

  10. jeremyclarke

    Starkov I’m pretty sure the answer to your question is in the slides themselves. You should take a look through them, or else watch the video of the talk to learn more.

    April 19th, 2012 at 11:24 am

Add new comment (email only seen by Jeremy)