Live data from Hacker News

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

adamwathan.me

51–60 of 108 posts

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

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

The biggest win when using functional css, or css utility classes, is that it is extracted out into a library already, in which case there is nothing to create or maintain (just the downside of messy classnames).

https://tailwindcss.com

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

#53
>What if we wanted to change how the author bio looked without changing how the article preview looks?

>Before, we could just open up our stylesheet and choose new styles for either of the two components. Now we'd need to edit the HTML! Blasphemy!

The reason you can't is because the markup declares two things to be equivalent, obviously then CSS can't tell them apart. You're not mixing concerns you're lamenting the fact that CSS can't be concerned with markup.

Throwing separation of concerns overboard and making HTML concerned with styling doesn't seem the best resolution.

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

#54
post #38

As a designer, the only thing that's important for me in managing CSS is isolation of styles. I apply a reset at the top to make everything as minimal as possible and then apply styling to each element and the naming convention would be such that it applies pretty much only to that element (or only that and its children if I'm being lazy). If the markup changes, the CSS changes. The nested SCSS should closely mirror…

I think one of the major advantages of Web Components is that styles can be isolated without the need for name-spacing. There is no need to carefully structure CSS according to the DOM, because this isolation is included with the shadow DOM. Incorporating CSS grid takes this even further, allowing these isolated designs to be responsive to the layout without needing to know what it is.

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

#55
post #49
post #46

Earlier quoted context omitted.

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.

That's the problem functional CSS solves: class naming doesn't relay on developer intervention, it's just a translation of the utility.

Product-card is not an utility, that's why it's a problem to maintain such classes.

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

#56
post #38

As a designer, the only thing that's important for me in managing CSS is isolation of styles. I apply a reset at the top to make everything as minimal as possible and then apply styling to each element and the naming convention would be such that it applies pretty much only to that element (or only that and its children if I'm being lazy). If the markup changes, the CSS changes. The nested SCSS should closely mirror…

[deleted]

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

#57
post #43
post #33

Earlier quoted context omitted.

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?

From experience with co-workers: Yep, and lots of !important

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

#58
post #8

From my experience, using utility classes like this just means that you'll have a lot of messy overriding to do when your reusable components need to look different in different places. Personally I think visual consistency is important and you shouldn't make things look different in different places, but it's not always up to me.

Let me see this:

.body--homepage .searchbox { color: red }

but, you use .searchbox on other section and you want it green

.body--article .searchbox { color: yellow }

To me this sounds an akward usecase but you can do this with functional classes no problem: just write the class to the point you want to change on whatever place you are instead of relegating these conditionals to the CSS.

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

#59
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'v…

This is the equivalent of predefined variables (usable in any preprocessor and now even in plain CSS), nothing specific about Tailwind here. Except for the fact that in the case of Tailwind they are tied to properties, but they are defined globally under the hood, so this doesn't change anything.

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

#60
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?

Changing the saturation of the red and causing it to look messy alongside surrounding elements/images? Or introducing colorblindness concerns elsewhere in the app?
Post reply on HN