I think I see the issue here. You are looking at Atomic CSS as it is authored but what I am discussing here is the end result
“Atomic CSS” is not a tool, it is about transferring styling from style sheets to markup/html.
Wish I get your point. Things gonna clear if we can separate the whole “Atomic CSS” concept into two parts: the “authoring time” and the end result.
For the end result, It’s obvious to see that Atomic CSS borrows many of pros from inline styles, to stop the specificity war (by flattening all the class specificity) and since classnames now describes very pure presentation, there is few scenario to use content-derived classnames or context-based selector hence it work around the global namespace and scope issues.
To make things better, using class instead of inline styles means better caching and easily static analysis which makes not only dead code elimination possible (where atomizer comes to play), but also classnames uglification/minification possible. It’s maybe a little weird but now I see “Atomic CSS” as a perfect compile-target. It shares many of wisdom with CSS-in-JS or CSS Modules approach.
For the “authoring time”, I admitted I still feel uncomfortable to write bunch of classnames like Mt(10px) or M-10 into my html. Yeah as you said that’s the part I dislike yet and feel like “back to old time”.
which means “Atomic CSS” must work for some people, hence it cannot be all wrong.
That is true. I should recall my statement saying “Atomic CSS is wrong”. It is sort of a misusing of language :p
I considered I should add “Atomic CSS” into my “css-sucks-2015” slides, mark it as one of the cool shit and introduce it a little to people when I give a talk next time.