[andrenotgiant]

When you get to the level of abstraction demonstrated in the Facebook Margins example, you have so many classes for each element that you may as well go back to inline styles.

This also enables inconsistent UI in the front-end: some of my page-headers can have .mbl "Large bottom margins" and some could have .mbs "Small bottom margins".

[FredFredrickson]

Whenever I'm writing CSS and I start getting to the point where I question whether or not I might as well be using inline styles, I know I'm doing something wrong and take a step back to evaluate where I went wrong.

[mrxd]

You're right that this example is no more semantic than inline styles, but that's the extent of the similarities.

If you want to update all the large margins across the app, you can do that in one place. That wouldn't be possible using inline styles.

You can also enforce style guide standards. Only three margin sizes are allowed: small, medium, large. Inline styles obviously allow for much more variability.

[masklinn]

> If you want to update all the large margins across the app, you can do that in one place. That wouldn't be possible using inline styles.

Sure can, your pages are generated, generate the styles from config or constants. There, I fixed it.

[ahallock]

I had a similar experience recently when I was using many compose-able CSS styles. My solution was to use a preprocessor and make an aggregate style; for example: <li class="u-paddingLarge t-important">

would become: <li class="MyImportantItem">

with the SASS being: .MyImportantItem { @extend .u-paddingLarge; @extend .t-important; }

You can avoid writing inline styles, keep things DRY, and still have compose-able styles.