DRY CSS – Slides from my ConFoo 2012 talk

10 Replies to “DRY CSS – Slides from my ConFoo 2012 talk”

1. You’re my favorite nerd.

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

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

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

5. 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 ;)

6. 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?

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

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

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

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