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.
CSS Utility Classes and “Separation of Concerns” (2017)
51–60 of 108 posts
Re: CSS Utility Classes and “Separation of Concerns” (2017)
#52Re: CSS Utility Classes and “Separation of Concerns” (2017)
#53>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)
#54As 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…
Re: CSS Utility Classes and “Separation of Concerns” (2017)
#55Earlier 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.
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)
#56As 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…
Re: CSS Utility Classes and “Separation of Concerns” (2017)
#57Earlier 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?
Re: CSS Utility Classes and “Separation of Concerns” (2017)
#58From 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.
.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> 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…
Re: CSS Utility Classes and “Separation of Concerns” (2017)
#60Maintenance 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?