If you're doing class='centered' or class='with_padding', I don't see any reason not to just do style='align-self:center;' or style='padding: 1rem;' instead. The class names communicate less (Is that centering the content of the element, or the element itself? Is that vertical or horizontal centering, or both? Is the text being centered?). And it doesn't allow you to make sitewide changes like a semantic class does (You might want to change all .blog-title elements from centered to left-aligned, but do you really want to change all .centered elements from centered to left-aligned?). I'd go so far as to say this is an antipattern.

Disagree. This is utility classing and you can target pseudo elements and deal with responsiveness. Tailwind is pretty popular and uses this methodology.

To be clear: putting `class='centered'` in your HTML is absolutely mixing concerns. That's exactly the problem I'm pointing out.

> Typically you have a design system that keeps things consistent. So you would have maybe 5-6 different padding sizes, eg padding-s, padding-xl or whatever. That's why you don't just do style='padding: 1rem;'.

Well, I'm not saying you should do style='padding: 1rem;', 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. The solution isn't to use inline CSS, it's to use semantic class names.

I can see the convenience of naming your padding sizes for consistency: that's what SASS inheritance does.

> As for me using .centered, it was just a quick example, and you took it in bad faith and now are nitpicking minor details.

1. Cool it. Nobody is attacking you, you don't need to attack me. We're discussing ideas, not each others' faith.

2. 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'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.

For the record, I didn't flag you.

> 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".

How is the proliferation of "padding-s", "padding-left-s", "padding-top-left-bottom" any better?

The solution here is don't do either of these things. Strictly stick to semantics. "primary-button", "secondary-button", "post-header", "comment-header", etc.

> 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.

Just because a lot of people do something doesn't mean it's a good thing to do.