Scalable and Maintainable CSS Approaches

This is something I've been thinking a lot about recently, and while all of these approaches solve some problems I think the requirement for maintainable CSS is a fundamentally different approach to the purpose of CSS. Once you make the mental switch from "CSS is the stuff that I do to make the things that I build look right" to "CSS is a component of everything I build" it becomes easier to see what I mean. It's not about "I need to be able to reuse this font size" as much as it is "I want to reuse this widget when I am display text in this way on any page".<p>In other words, if you want to build something maintainable, start thinking about all the ways you can help people not write custom CSS at all.<p>Also, LESS and SASS at their core do little to help with this problem, and can even hurt you with unintentional specificity (due to nesting) that hurts reusability. Mixins help you think "reusability" but they can really easily be misused in ways similar to how people are misusing CSS right now. This is by no means an attack on LESS/SASS, which I love. It is just a reaction to working on a large project that is making the switch and seeing the fallout.

The approaches laid out seem reasonable, but it's hard not to feel as if the web dev community has moved on to using LESS and SASS as a means of addressing some of the same issues.

I find that a combination of SMACSS and a lot of shared helper classes (left, right, center, size-&#60;n&#62;, ...) really helps with maintainability.<p>I don't get the DRY CSS approach of wanting to avoid changing HTML. CSS changes are much more expensive, as they can affect the design on unrelated pages (especially if you don't write modular CSS), which means more testing.<p>And are there any real world use cases or benefits of "semantic class names"? If not, and if you think they hurt maintainability, why would anyone advocate them?

They invented a solution for scalable and maintainable UIs many, many years ago. Its called a widget.