It’s not exactly a thrill ride, coming in at 51 minutes, but here’s the full audio+slides video of my presentation about DRY CSS, my “simple yet powerful CSS architecture that avoids duplication and increases design consistency by grouping shared properties together rather than redefining them over and over”. Sorry there’s not footage of my pretty face, I recorded this using Screen Capture in QuickTime and Voice Memos on my iPhone (using the earbud mic).
For the impatient, you can also go through just the slides on slideshare.
I find that when working in a team, styles get repeated (for numerous reasons – laziness, a lack of CSS understanding, laziness, being rushed and laziness, to name a few). Especially on work-in-progress works. But this certainly is the ideal to strive for and it’s fun trying to see just how small the CSS can become.
Great talk!
No matter what getting a team to consistently apply a CSS pattern is going to be nearly impossible. I like to think using this DRY style would make it easier, cause at least you could say “Use the groups that are there! Talk to me if you want to add a group!” but ultimately laziness, laziness and laziness are going to result in people creating random selectors all over. At least as the manager you could just re-organize and DRY their code later.
(Reposted comment for the previous entry before I saw this newer one. The other one could be removed if you want.)
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