DRYing CSS for brevity, unity and maintainability

My blog post about the talk:

http://simianuprising.com/2012/02/28/dry-css-slides-from-my-confoo-2012-talk/

The slides on Slideshare:

http://www.slideshare.net/jeremyclarke/dry-css-a-dontrepeatyourself-methodology-for-creating-efficient-unified-and-scalable-stylesheets

Seems you can't make a link in these comments so fire up your copy/paste!

Can't delete a comment! I with I could delete this duplicate comment that the system created!

good presentation, and I plan to implement concepts. Only complaint is that the core idea wasn't very complex so I thought the content was a bit like 'butter spread over too much bread' in that it could have been covered in less time.

Jeremy is a really good speaker.

But I feel he was too self confident on this talk.

The technique he demonstrate was mostly base on the tool he use and how it let him organize his code. This being said, most people have their own tools and for them the talk was too turned over this tool than a more general Principe.

Next thing, I feel the way he turned back to renown method like Nicole Sullivan OOCSS (I doubt you put as research as she did for his own method on your own method), and pre-processor CSS (I mean, SASS is based on Ruby and LESS on Javascript, how is this not a proof of being future friendly? These technologies exist from a long time and don't seem like going to disappear anytime soon, and certainly not more than CSS itself).

To finish, being DRY in CSS is ultimately a good thing. But this talk missed more research and a more solid approach. Finaly, it need a little bit more humility.

I feel Jeremy is a good speaker and interacts with the audience well.

The content of the talk is where I have my biggest disagreements with. He mentioned OOCSS once, but never really elaborated how his strategy to DRY utilizes it. Some of his strategies seemed to contradict OOCSS. He told the audience to ignore the class naming, which I felt was a good teaching point to drive home why he made those naming decisions.

As a reply to those who feel I didn't explain how OOCSS and DRY are compatible, the idea I was trying to get across was that OOCSS and DRY are not the same type of thing, and that all the properties of OOCSS other than how you get it onto your HTML are compatible.

DRY just offers a way to organize your selectors and avoid duplicating properties, similar to mixins in LESS/SASS, so it is in fact a replacement for those technologies.

On the other hand, OOCSS (and SMACSS, which is probably even better) are systems for deciding on groups/names that define your style. If you want to use OOCSS or SMACSS then you can still use DRY, just use the other system to decide what your DRY Groups will be, and use DRY to think about/implement the groups.

Those systems often encourage you to instead add non-semantic classes into your HTML, which is not how CSS classes are supposed to be used. In that sense my system DOES contradict OOCSS, but IMHO only in the least important way. No one would say that using OOCSS with LESS "contradicts" it, it's just another way to organize your selectors, it's the same with DRY! If you don't care about using CSS in the way it was meant to be used (style separate from content) then that's fine, you can do whatever you want. My system is intended for people who see the benefits of style/content separation and want an elegant, standards-based solution.

Also if you see this Simon, please let me know what kind of research I could have done to augment my talk, as I would like to investigate anything relevant that I missed. I tried to research everything I could find that was in the same field, both when I myself was trying to find a way to DRY my CSS and later when I was preparing the talk.

I was very happy with the concepts taught in this session. Not knowing much about LESS and SASS I think the summary of the technologies he gave was good. His point was to give people a new perspective on optimizing CSS and he did that.