CSS Utility Classes and “Separation of Concerns” (2017) • Hacker News Board

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

#21

Post by csande17 » Sat, Nov 16, 2019, 7:27 PM UTC

XCSme wrote: post #20

0xFACEFEED wrote: post #4

For me, CSS has been a Solved Problem™ for 5 years now. If a website is small then I write plain HTML/CSS/JS in the old school way and all of these abstractions/systems are YAGNI. If a website is large enough for these abstractions to matter then I'm using React with inline CSS. I get reusability and composition without a noticeable performance tradeoff. You can still build your components to decouple style from cont…

How do you re-use this inline CSS?

Not the parent, but the approach I've seen in React is to treat inline CSS as objects like "{ fontWeight: "bold", color: "#000" }". So to re-use it, you can either put it in a constant or make a component that applies the styles to an element (and maybe takes props to override them).

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

#22

Post by csande17 » Sat, Nov 16, 2019, 7:29 PM UTC

1_player wrote: post #17

csande17 wrote: post #16

I think the utility-based approach overlooks an important point: semantic class names are useful for a lot of things besides writing your styles. "Codeless tracking" systems let you put in the CSS selector for a button and find out how many people clicked on it. UI test automation tools let you specify the CSS selector of an element to click on. User stylesheets let people make tweaks to your site if they have access…

Nothing stops you from adding a semantic class name or ID to a tag for easy reference.

Right, but it goes from being something you get for free to being something you have to go out of your way to do. Which can matter, especially on projects where you're designing a site/theme to hand off to someone less technical.

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

#23

Post by blauwhelm » Sat, Nov 16, 2019, 7:29 PM UTC

I feel like one thing that isn't addressed is the way designs are often made. Using utility classes requires that your designer is also aware of this and uses it. My experience is that most of the time this is not the case. You will end up having to make a lot of utility classes for single cases.

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

#24

Post by circlingthesun » Sat, Nov 16, 2019, 7:32 PM UTC

I love the analysis in this post. I think utility functions along with a set of design tokens (Styled System [1] / ThemeUI [2]) is a better mechanism and achieves the same end goal as utility-first CSS, at least in the React ecosystem.

1. https://styled-system.com/ 2. https://theme-ui.com/

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

#25

Post by listenallyall » Sat, Nov 16, 2019, 7:33 PM UTC

(Article is from 2017). TailwindCSS is a terrific library.

One area that wasn't covered was the ease of creating truly responsive layouts, inline, by defining different utility classes to the same elements based on screen size. "Responsive" is so much more than just the placement -- quite often, mobile version needs different font sizes, overflow behavior, thinner margins (since there is less screen space), etc. Very easy to do with the utility approach.

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

#26

Post by XCSme » Sat, Nov 16, 2019, 7:35 PM UTC

csande17 wrote: post #21

XCSme wrote: post #20

Earlier quoted context omitted.

How do you re-use this inline CSS?

Not the parent, but the approach I've seen in React is to treat inline CSS as objects like "{ fontWeight: "bold", color: "#000" }". So to re-use it, you can either put it in a constant or make a component that applies the styles to an element (and maybe takes props to override them).

I was asking because doing this just looks like normal CSS, where you define a class and use it in multiple places, only that it's in JS instead, so you still have all the "problems" mentioned in the article.

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

#27

Post by chrisweekly » Sat, Nov 16, 2019, 7:44 PM UTC

XCSme wrote: 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…

The subatomic class names aren't cryptic if you spend any time at all using them. But more objectively, you skipped the critically important composition phase! That's where you take those class names and group them in ways that make sense for your component hierarchy. Tailwind supports this directly via `@apply`. (Other equivalent mechanisms for composition exist.) If you're hand-writing raw HTML and manipulating the DOM directly, you're really missing out. Component-oriented architecture (exemplified by React) is powerful, and implies a different "shape" for the boundaries implied by the phrase "separation of concerns". In a world where everything can be encapsulated in components -- including styling and error boundaries -- hanging on to certain rules of thumb or best practices applicable to older paradigms can be limiting and problematic. "The difficulty lies not in the new ideas, but in letting go of the old."

All that said, 100% agreed with your closing sentence! :)

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

#28

Post by chrisweekly » Sat, Nov 16, 2019, 7:48 PM UTC

kian wrote: post #10

thinkloop wrote: post #6

The real issue with css is that there is an enormous amount of code re-use while at the same time almost no code-reuse at all. The author's example highlights this perfectly: he has a "media-card" representing both the "author-bio" and "article-preview" but the "author-bio", in this case, needs to be slightly different. This, to me, is the quintessential css problem. Almost nothing in css is identical, but almost eve…

In programming, this problem would be solved with something like higher order functions or parametric data types, allowing us to both abstract out the commonalities and maintain incredibly specific, easily modifiable, highly customized functionality. Is there an analog in the CSS world?

There doesn't need to be, given CSS-in-JS!

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

#29

Post by chrisweekly » Sat, Nov 16, 2019, 7:50 PM UTC

MODS: OP is from August, 2017; maybe add "(2017)" to the title given how long 27 months is in webdev?

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

#30

Post by pixelbash » Sat, Nov 16, 2019, 7:55 PM UTC

cousin_it wrote: post #12

The decision to make CSS libraries that are reusable across all parts of your application is spot on. Also it helps with theming, eg dark mode. To avoid listing tons of classes on each element, you can use something like less: .my-class { .utility-class-1; .utility-class-2; } Reusable constants also help a lot.

On the dark mode thing, another way to do this is using css variables like --color-foreground for example. The whole site can have dynamic colour themes with minimal effort after that.