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

81–90 of 108 posts

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

#81

Post by aliveupstairs »

tqkxzugoaupvwqr wrote: post #73

Question: I used CSS utility classes for building components in VueJS. The problem I ran into was that I wanted to apply classes only when certain conditions are met, i.e. style the component slightly differently based on its state. This caused me to check the condition repeatedly – once per class I want to apply. Is there a better way, e.g. applying all classes together after checking once? TypeScript/JavaScript: ex…

the docs:

https://vuejs.org/v2/guide/class-and-style.html#Binding-HTML...

https://vuejs.org/v2/guide/class-and-style.html#Array-Syntax

In your template:

a)

b)

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

#83

Post by ehnto »

I use a method called Context and Components. The idea being to build components, and to modify those components of they need to change base on context.

From my experience, reusable CSS is somewhat of a red herring. Maintainable and easily locates CSS is where you get productivity gains. If you don't know what you habe because there are hundreds of utility classes then what good is it. Also, if you are using utility classes why not just inline CSS? "red-border" is jusr as

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

#84

Post by ehnto »

I use a method called Context and Components. The idea being to build components, and to modify those components if they need to change base on context.

If I need to change the product card on my site it is at component/product-card.scss. If I want it to be different on thr homepage I change it at context/home-page.scss and I targetit with .home-page .product-card. Simple stuff, no inheritance issues either.

From my experience, reusable CSS is somewhat of a red herring. Maintainable and easily located CSS is where you get productivity gains. If you don't know what you have because there are hundreds of utility classes then what good is it.

Also, if you are using utility classes why not just inline CSS? "red-border white-background pad-20" is just as bad.

I wrote an article explaining the method here: https://polylab.co/articles/ccm-contexts-and-components-css....

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

#85

Post by 0xFACEFEED »

pixelbash wrote: post #32
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?

Media queries as normal.

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

#86

Post by 0xFACEFEED »

Izkata wrote: post #31
XCSme wrote: post #26

Earlier quoted context omitted.

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.

With the inline CSS approach, components are your reusable entities not CSS classes.

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

#87

Post by 0xFACEFEED »

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?

Under the hood it’s still CSS classes. You just define your CSS classes as element properties and the library takes care of the rest.

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

#88

Post by karaterobot »

ehnto wrote: post #84

I use a method called Context and Components. The idea being to build components, and to modify those components if they need to change base on context. If I need to change the product card on my site it is at component/product-card.scss. If I want it to be different on thr homepage I change it at context/home-page.scss and I targetit with .home-page .product-card. Simple stuff, no inheritance issues either. From my…

I didn't know there was a name for this method, but it's what I've settled on as well: Namespace the classes by their component's class name, and then override them, if necessary, in another namespaced context. It's pretty simple, as safe as can be expected, and works well for sites of all sizes.

The only bullet you have to bite is occasionally repeating yourself, but as you say, that part of CSS never really worked well anyway.

If using a pre-processor like Stylus or Sass, you can get a lot of composability with mixins and extensions, if that's what you want, and these can even be cleaner and more flexible than utility classes, because they can use parameters and basic logic.

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

#89

Post by martinbooth »

There are lots of positive comments in this thread in support of this approach and I think it's great when anyone challenges the status quo.

It is more common these days than it was for websites to support multiple styles/layouts. Whether that's because they're responsive or because they allow you to enable dark mode or because they support rtl layouts. Class names such as text-dark-soft or align-right will be misleading if text-dark-soft ends up closer to white and align-right is left aligned as a website is evolved to support these features.

Not a criticism of this approach; this is easily fixed by using names such as text-emphasized-soft or align-start (for example), just pointing out the examples in this article could be lead to problems

CSS variables can also be used to encourage picking colors or padding/margin from a curated list. The approach in this article is not required to solve that problem

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

#90

Post by saagarjha »

firefoxd wrote: post #63

What I figured out over the years, is that CSS is not an afterthought. You need to engineer a solution for your design as you are building the html.

If you treat your CSS as a value-add, I've found you can often treat it that way. I've designed sites that work fine in text-based browsers, and then I stick CSS on it to make it look pretty on your phone.
Post reply on HN