I find that a combination of SMACSS and a lot of shared helper classes (left, right, center, size-<n>, ...) really helps with maintainability.
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.
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?
> And are there any real world use cases or benefits of
> "semantic class names"?
Yes. Class names tell what the stuff is, CSS rules tell how to style it.
Once you see blue 14px text on the left which has class "red-12px-right" you are enlightened.
"Class names tell what the stuff is" is not a "real world use case or benefit". In an HTML document, the defined vocabulary is the HTML elements and some attributes. Class names are styling hooks, with the exception of microdata.
'red-12px-right' is a stupid class name (and a strawman). A better example would be 'heading-primary', instead of a "semantic" approach like '.news h2 { }' (which could have the same styles as '.blogs h1' and '.members h3'...)
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.
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?