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 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.
> 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.
For example, I probably always want h1 elements to have the same font/weight/size. That's style, and should be defined on the h1.
In contrast, the h1 within a blog post may be positioned very differently from the h1 within a video page, so I'd want to define that in the blog post and video page styles, respectively.
Of course, where this gets complicated, is that there's not always a clear boundary between style and layout. For example, I might always want the same amount of space under the h1 between the h1 and the content it titles (style?) but the top/left/right spacing is probably more dependent on the context (layout?). There are some hard to communicate tradeoffs here.