We just ported our tree from straight CSS to Compass and without doing anything clever at all, it's been a huge win.<p>Straight off the bat, going from CSS/Blueprint to Sass/Compass got rid of ~300 lines of styling, simply because Sass is so much more expressive.<p>Then we went through the code and extracted all the color literals and stuck them in a variables file. Instantly we were able to play with site colors without search/replace drama. The stylesheets themselves also got far more readable, since you never have to work out in your head what a particular hex string probably meant. Little things like that remove friction from the dev process, and are totally worth it.<p>Of course, once we had all the colors in one place, it became obvious that we had, for instance, 4-5 different oranges all within 15% of each other. We kept the variable definitions, but made them all the same base color.<p>We repeated the same process with font sizes.<p>Finally, we went through all our markup and evicted the Blueprintisms, moving them to the stylesheets via Chris' Blueprint Compass mixins. This was more than a "semantic vs. visual" hygiene win. Playing with column widths involved finding where Blueprint classes were passed in or coded into markup. Now they're right there in the CSS, where you expect them to be.<p>We've got tons of opportunities to reduce the stylesheets further by macro-izing or mixin-izing, but just by transliterating our code from CSS to Compass we got a big enough win to be happy for this dev cycle.<p>Can't recommend Compass highly enough. Great work, Chris.
I think it's a good thing to have these abstractions available, and as the article notes it's better to keep these at a high level. It's not a call to extend the CSS specification or to add support for abstractions in browsers.<p>I have always found it easier to avoid bugs when parsers are dealing with canonical forms. In other words, make the browser support the absolute minimum syntax required to achieve every effect in CSS. Anything that's merely "syntactic sugar" should be handled at higher levels, and then "compiled down" into raw CSS.<p>This restriction not only makes it easier for browsers to agree, but it means that you're only likely to find quirks in your higher-level <i>tools</i>: which, importantly, are <i>outside the end user's domain</i>. Bad tools can be replaced, or you can adjust your flow to insert post-processing steps that fix the output. You don't need as many "debugging tools" because you can simply examine the generated files to tell if something was interpreted correctly (whereas, if a browser isn't seeing things the way you think, good luck figuring that out without extra tools).
While I think stylesheet abstraction is a good idea, most programmers (including the author) don't seem to use all the abstraction mechanisms that are already available in CSS. For example, the change-all-the-colors-on-the-page-at-once problem would go away if webmasters factored all the elements of a given color into a single rule:<p><pre><code> span.fl,
span.a,
a.link,
cite { color: #ef88bb; }
body, div.leftnav, div.logo { background-color: #333; }
</code></pre>
You're also supposed to rely on the cascade for fonts and stuff: set them once on the body and then let all descendants inherit them.<p>There're some real problems when you want to set, say, the border color of one element to the color of a bunch of others, but a lot of the CSS maintenance problems I see (and have written ;-)) come from developers just going through the list of elements and writing the properties for each. The cascade was supposed to save you from this; CSS <i>already</i> has a pretty powerful abstraction mechanism.
If you don't "get sass", please take a couple minutes to read the article -- if you've never had to live the life of a front-end engineer, you have no idea how hard it is to do that job with the tool that is CSS. Balancing browser support, design, and constantly changing requirements is hard. Doing it without a form of abstraction at your disposal is lunacy.<p>I would also like to point out that this post is not an advertisement for compass or even Sass. It's a rebuttal to the people who think any advancement in stylesheet technology is unnecessary. Sass is an implementation of these ideas and compass shows their power in action. But it really is an argument for a new approach.
he misses out 2 of the major disadvantages,
1. you add a dependancy / stage of complexity in the build stage,
2. you lose a direct mapping from your dom elements to your css, ie I can click inspect something in firebug and see on what line of what css file I need to change<p>and to be honest since I dont find css that hard to manage those tradeoffs are enough to put me off using one.<p>also worth mentioning css variables have been introduced, just waiting for ie? now
From my own experience if you understand the cascade principle and specificity well you can get away with very compact and well written CSS files. Multi-classing is another area where developers are only now leverage to its maximum, for example if you have a look at the way the jQueryUI CSS works, by for example specifying the items you wish at the end of the file as additional classes you can introduce quite a bit of additional functionality in a much simpler way than calling functions.<p>For example:<p><pre><code> .box{define only properties that you
do not want to
change from box to box
}
.boxColors{background:#fff;
color: #f60}
.arial13{font-family:arial;font-size:13px
<div class="box boxColors arial13"></div>
</code></pre>
This way your classes can be used as 'functions'. As a rule, define typography and colors and opacity this way and you can keep it simple.<p>CSS was developed as an abstraction to HTML. Any abstraction to the CSS other than adding pre-processors would create serious integration problems with the DOM model and JavaScript. (See a good discussion of this at <a href="http://people.opera.com/howcome/2006/phd/#ch-problems" rel="nofollow">http://people.opera.com/howcome/2006/phd/#ch-problems</a> by
Håkon Wium Lie the original developer of CSS).<p>Any productivity pre-processors our our business and not of the spec developers.
<i>We have the same in web design. Grids, buttons, tabs, menus, font rhythm, etc are all considered standard elements for a website.</i><p>Tell that to a Flash developer. This is one of my pet peeves with Flash sites. No interface standardisation.