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.
CSS Utility Classes and “Separation of Concerns” (2017)
41–50 of 108 posts
Re: CSS Utility Classes and “Separation of Concerns” (2017)
#42> 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…
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)
#43Earlier 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!
Re: CSS Utility Classes and “Separation of Concerns” (2017)
#44Re: CSS Utility Classes and “Separation of Concerns” (2017)
#45Re: CSS Utility Classes and “Separation of Concerns” (2017)
#46Maintenance 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.
Would you mantain .display--block? how? .color--red?
Re: CSS Utility Classes and “Separation of Concerns” (2017)
#47> 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…
Re: CSS Utility Classes and “Separation of Concerns” (2017)
#48A-b_c is so multiplicative
Re: CSS Utility Classes and “Separation of Concerns” (2017)
#49Maintenance 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?