3 ms·
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 alwa
by kerkeslager 6y ago
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.
- dsego 6y agoAnd 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'.
- kerkeslager 6y agoIf 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.
- metalforever 6y agoThis mixing of concerns was garbage and still is garbage, regardless of whether its popular now.
- kerkeslager 6y agoTo be clear: putting `class='centered'` in your HTML is absolutely mixing concerns. That's exactly the problem I'm pointing out.
- dsego 6y agoTypically 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;'. Instead you assign a predefined padding class that's defined by your design system. As for me using .centered, it was just a quick example, and you took it in bad faith and now are nitpicking minor details. Sitewide changes are a trade-off, if you make one easy (adjusting one parameter for a class of elements) you make others more difficult. Like, what if you need to change only some blog-title elements from centered to left-aligned in your system, do you create blog-title-left-aligned? I don't think the problem you pose is any more relevant than any other possible arrangement of html/css changes.
- kerkeslager 6y ago> 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.
- dsego 6y ago> 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.
- Evansbee 6y agoDisagree. This is utility classing and you can target pseudo elements and deal with responsiveness. Tailwind is pretty popular and uses this methodology.