Live data from Hacker News

CSS Utility Classes and “Separation of Concerns” (2017)

adamwathan.me

41–50 of 108 posts

Re: CSS Utility Classes and “Separation of Concerns” (2017)

#41
I really like how the author progressed from semantic to utility with examples. This approach made it really easy to understand the... uh... utility of utility classes.

The answer to anyone asking "how is this not inline styles", is in the article. With utility CSS, you don't use 100% of everything that CSS can do, and just pick the exact snippets you need for your theme.

Re: CSS Utility Classes and “Separation of Concerns” (2017)

#42
post #19

> Isn't this just inline styles? Yes it is. I personally don't like the end result, where by "separating the concerns" you end up hardcoding your style in the HTML markup. For me the utility classes are just exposing the CSS rules to the HTML markup, which I think is actually the opposite of separation of concerns because I when I think of "separate" I think the most of writing code in two different files. > The amaz…

No it's not.

You cannot do this in inline styles:

It's a false premise to say this is "inline CSS". Inline styles are one subset of the entire CSS world and functional classes can hold dozens of advantadges inline CSS doesn't have.

Re: CSS Utility Classes and “Separation of Concerns” (2017)

#43
post #33

Earlier quoted context omitted.

At least React's "pass an object to the `style` prop" makes it relatively easy to do that overriding. With utility classes, your code has no way of knowing that "bg-red" should override "bg-blue". (And frequently it won't, if "bg-blue" happens to come later in the CSS file.) So people end up inner-plaforming their own clunky solutions on top.

You would be surprised how many people do not know that the order of classes in the source file, not the class="" attribute, matters. See my (totally unscientific, yet scary) poll of my audience, which heavily leans towards frontend with a focus on React: https://mobile.twitter.com/mxstbr/status/1038073603311448064... Only 43% got it correct!

If you do not know basic stuff like that how can you even write CSS at all? Trial and error?

Re: CSS Utility Classes and “Separation of Concerns” (2017)

#44
Maintenance of these utility class CSS codebases is such a pain. I've had the pleasure of dealing with it. What if you want to tweak one of your utility classes ever so slightly? If your codebase is big enough, you've just created enormous amounts of potential regressions.

Re: CSS Utility Classes and “Separation of Concerns” (2017)

#46
post #44

Maintenance of these utility class CSS codebases is such a pain. I've had the pleasure of dealing with it. What if you want to tweak one of your utility classes ever so slightly? If your codebase is big enough, you've just created enormous amounts of potential regressions.

Give me an example of that.

Would you mantain .display--block? how? .color--red?

Re: CSS Utility Classes and “Separation of Concerns” (2017)

#47
post #19

> Isn't this just inline styles? Yes it is. I personally don't like the end result, where by "separating the concerns" you end up hardcoding your style in the HTML markup. For me the utility classes are just exposing the CSS rules to the HTML markup, which I think is actually the opposite of separation of concerns because I when I think of "separate" I think the most of writing code in two different files. > The amaz…

In addition to meeritas point about pseudo classes and media queries, I'd add that the fact that it narrows down the space is an important factor. The classes mean that I need to find the best fit rather than spend hours matching pixels by hand. It's like going from drawing charts on blank paper to grid paper. You stay within certain boundaries. It seems like a detail but I find that in practice (and in fairness, I've only been using Tailwind a bit so far), this makes a significant difference to the way I think and work with UI.

Re: CSS Utility Classes and “Separation of Concerns” (2017)

#49
post #46
post #44

Maintenance of these utility class CSS codebases is such a pain. I've had the pleasure of dealing with it. What if you want to tweak one of your utility classes ever so slightly? If your codebase is big enough, you've just created enormous amounts of potential regressions.

Give me an example of that. Would you mantain .display--block? how? .color--red?

It would be some domain-specific component. Like .product-card. I don't see the examples you've given. Those are so literal, you might as well use inline styles at that point.
Post reply on HN