One thing I've been realizing is that layout and style are two different thing. Layout I almost always want done on the parent element, and style, I almost always want done on the child element.
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.
And then you discover semantic classes for styling elements, eg `.amazing_h1.with_padding` and use nested selectors for layout like `.blog_post > h1` or maybe even utility classes `.amazing_h1.with_padding.centered'.
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.
> 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.
> 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.