> I'm saying that padding-s has all the downsides of mixing styles into your markup, with none of the clarity of just using inline CSS. I don't think it does,

> I'm saying that padding-s has all the downsides of mixing styles into your markup, with none of the clarity of just using inline CSS. I don't think it does, it's semantic with respect to your design system, not your content. The use of utility classes is to avoid the proliferation of "header-foo", "header-foo-large-padding", "button-foo", "button-foo-large-padding" or even worse usage of overly specific selectors, relying on element position, eg .main-content > header-foo { padding: 1rem } etc . Instead, you can just "header-foo.p3", "button-foo.p3". > 1. Cool it. Nobody is attacking you, you don't need to attack me. Sorry, not a native speaker, it didn't sound like an attack in my mind. With argument in bad faith I meant fixating on the simplified .centered example instead of discussing the general idea of design systems and utility classes. I guess cause I got flagged I need to "cool it". > I've encountered this antipattern in production code, so regardless of whether you were actually proposing it as a serious idea, some people do take this idea seriously, so it needs to be addressed. The problems I pointed out aren't theoretical: I've dealt with them in practice. I don't understand this argument. A lot of major css libs and frameworks use utility classes. I'm sure they deal with production code and practice all the time. I know I do. This comment I take as very dismissive.