Inspired by Nicole Sullivan’s blog on Massive CSS and her continuing work on OOCSS, I recently gave a presentation to a number of colleagues at Huddle.net on how we should go forward with our CSS architecture.
The premise was to explain how we should build new CSS in a DRY and highly composable way.
There are of course trade-offs and arguments for and against the implementation of a DRY CSS framework. In creating highly reusable code we also introduce risk, the cost of error becomes greater and the investment of time in quality assurance increases. I suggested that although this argument is perfectly valid you could raise similar arguments with regard to sandbox styling and its negative effects on the cascade.
To cement my point I compared “selector wars” to the game of Top Trumps. Like Top Trumps the selector (card) with the greatest specificity (points) wins. Selector wars is also like Top Trumps in that it’s fun when you’re a young but as an adult it seems really stupid. The only winning move is not to play.
As well as talking about the benefits of image spriting I also took the presentation as an opportunity to restate something I’ve been pushing for a long time: “No CSS browser hacks!“. If you understand the box model, has-layout bugs etc. you will find ways around these problems, usually this means adding more HTML markup. Of course there are valid reasons for forking code for browser compatibility, semi transparencies for one. The remaining hacks should be put along with the other associated styles and a concise comment provided.
I received some good feedback at the end of the presentation. The audience was mainly comprised of back-end developers and I think they appreciated the ideas given. Whether it is CSS or C#, DRY composable code is something we can all understand and agree on as a logical way forward for the benefit of performance and manageability.