Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

adamwathan.me

Post reply on HN
Print view View original

31–40 of 108 posts

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

#31

Post by Izkata »

XCSme wrote: post #26
csande17 wrote: post #21

Earlier quoted context omitted.

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.

The major downside of reused inline CSS is when you have to do minor tweaks (where active manipulation in the browser devtools is by far easier to find the right values) and those inline styles are on the page multiple times. Editing one class's rules is significantly easier than all the repeated inline styles.

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

#32

Post by pixelbash »

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 handle responsive with inline in react? Case switching in js?

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

#33

Post by mxstbr »

csande17 wrote: post #11
beizhia wrote: 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.

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)

#34

Post by koboll »

chrisweekly wrote: post #28
kian wrote: post #10

Earlier quoted context omitted.

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!

It's wild to me that most of the discourse around CSS-in-JS is about personal preference for how separation of concerns should be when its biggest advantage is totally orthogonal to that--it almost completely solves the issues of scope, specificity, and mapping styles to markup that so many different libraries and methodologies have been invented to cope with over the years.

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

#35

Post by koboll »

XCSme wrote: post #26
csande17 wrote: post #21

Earlier quoted context omitted.

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.

>where you define a class and use it in multiple places

If you're doing this in React, you should probably be reusing a component.

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

#36

Post by pixelbash »

This is a particular dilemma I've tried a lot of different approaches for. One thing the article didn't touch on is what happens on responsive, where often margins can change multiple times between desktop and mobile.

For a while now I've been effectively writing semantic css (nested or more recently bem) composed out of non semantic sass helper functions. The benefits of this are being able to think about namespacing in very simple terms. It can make for fairly large css output files though, something BEM helps with a bit.

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

#37

Post by coffeefirst »

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…

> There's no perfect way of doing things and everyone and every project is different.

Yep. I like utility classes (F.K.A. OOCSS, Atomic CSS, and Functional CSS) and use them all the time. But it's one tool amongst many. It's not reason to give up small namespaced components (e.g., BEM) or using inheritance when you're doing so clearly and deliberately (Zen Garden Method).

This debate, which is something like 25 years old at this point, always seems to assume a need for absolute purity. But one of the best things about CSS is, depending on what you're trying to build, these techniques can work really well together.

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

#38

Post by whytaka »

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 the DOM.

I can only imagine utility classes will simply create many problems with naming down the road. I would hate to have to deal with all that.

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

#39

Post by listenallyall »

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…

>> If it was written as ".text-margin { margin: 6px; }" then it was just a matter of changing one number

These types of examples basically never match real-world experience, it is never as easy as it sounds. Are you telling me the giant text in headers and small text inside buttons and condensed text in tables and indented text in lists and plain body text all share the same margin size? What happens with text adjacent to an image that itself has a margin applied to it? Or text next to an icon (which technically may be an icon font text glyph).

>> all the CSS rules for mobile in the inline class names.

most of the time, this works great. desktop and mobile can share, for example, font family, color, weight, background color, and use different font-size and padding, to account for the smaller dimensions on mobile. As a developer, having multiple styles inline are a constant reminder to be responsive-minded before making any style changes that might look fine on a dev machine with a huge screen.

you're correct there is no perfect way and projects differ -- but Tailwind's approach is often superior to alternatives

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

#40

Post by ken »

The fundamental problem I see is that CSS is far too weak for proper separation of concerns. You can't make a nice structure in HTML, and then style it with CSS. You have to structure your HTML from the start in a way that it's feasible to style it with CSS.

(That's why every CSS question on Stack Overflow has an answer that says "use this HTML: ... and this CSS: ...". It's rarely possible to use some random HTML and style it in an arbitrary way.)

The CSS designers decided to pick a purely declarative stylesheet language, which is a cool idea and has some interesting properties. One of the things you sacrifice with this decision, though, is the ability to structure the HTML as you wish. You've got two languages you need to play with, and you've got to tweak them in concert.

There's an alternate universe where they chose to use JavaScript as the styling language. The style layer runs in its own sandbox completely separate from any other JS on your page, and all it does is accept HTML trees and lay out and style them. You can structure your HTML in any way you want, and then write 3 lines of JS to style it any way you want. You can implement TeX-style word wrapping or media queries as a library. Your designers don't have to talk to your programmers when they change something, because the HTML is generic from the start.

Post reply on HN