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

101–108 of 108 posts

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

#101

Post by earthboundkid »

aliveupstairs wrote: post #81
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)

B) is not valid. It needs to be wrapped in an Array, not an Object.

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

#102

Post by ravenstine »

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 really like this.

At the risk of being a broken record, this is similar to an approach that I discovered and have talked about on HN before. I think your approach is a form of "separation of concerns" that makes sense because I've found that CSS becomes less tangled and more comprehensible if styles that represent a concept like a .product-card aren't concerned with how they are sized or positioned on a page; that's the job of something like `.home-page .product-card`, or, in my own practice, `#home-page-product-card` if the element is a layout singleton or `.home-page__product-card` if the element is repeated.

By doing this, not only can I look at my markup and understand what everything means(which I can't do easily with utility classes), but I never find myself needing to use things like `!important` which have consequences to their use.

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

#103

Post by inopinatus »

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…

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

Those of us who’ve used Tailwind in particular might write “just as good, but better”. The utility classes are satisfyingly regular and well documented. They are higher level than inline CSS, and though obviously congruent, I'd reject a claim of direct equivalence.

Tailwind is to inline styles what assembler is to machine code, and that’s a good thing. With inline styles there is no opportunity to use combinatorial selectors, or to specify units, breakpoints, and other stylistic preferences as part of the compiled utilities.

My experience of a semantic or domain-specific approach to class-based styling is a drop in maintainability and a rise in complications, duplication, and special cases. Especially so in larger, componentised applications. Thinking of elements as purely on-page structures (and not representational of anything greater) helps avoid layering violations, promotes generality of style, and creates more opportunities for extension and substitution.

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

#104

Post by whytaka »

IggleSniggle wrote: post #66
whytaka wrote: post #38

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…

I can definitely see the advantages! But don't you find yourself writing the exact same CSS hundreds or even thousands of times with this approach?

Yes and if anything I think I spoke too strongly. I do use classes that encompass a broader pattern, but they definitely don't go as far as "text-right", but perhaps something like, "card" for card based layouts.

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

#105

Post by ehnto »

inopinatus wrote: post #103
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…

> Also, if you are using utility classes why not just inline CSS? "red-border white-background pad-20" is just as bad. Those of us who’ve used Tailwind in particular might write “just as good, but better”. The utility classes are satisfyingly regular and well documented. They are higher level than inline CSS, and though obviously congruent, I'd reject a claim of direct equivalence. Tailwind is to inline styles what a…

I have heard good things about tailwind. Do you find a lack in flexibility with Tailwind? To use the same example, what if the client wants a product card to look different on the home page compared to the listing page, and again in the mini cart and checkout? One approach I have seen is four different components for each location, in which case you have traded cascading of CSS for duplication of markup/logic code.

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

#106

Post by luord »

This article is interesting, but not for anything having to do with CSS:

1. Start with a given approach, but say you feel something "off" because it doesn't quite fit "best practice xyz".

2. Use another approach, which also doesn't fit "best practice xyz".

3. Argue that the best practice shouldn't be a best practice.

This of course, should mean that the very first approach is just as alright as the second, yet here it is used to defend only the second (sure, there's a token acknowledgement of the first approach being valid too under the new assumption, but everything afterwards is a long "but not really, second one is the true better one").

Back to the topic at hand, the article depicts a circle: let's move away from inline css by... moving it one attribute over, to "class". The token attempt at contradicting this is unsuccessful one because, as much as there's no limit in the inline css you can do, there's no limit to the amount of classes you can add. So it all ends up feeling a bit self-defeating.

Ultimately, this article, IMO, is a good example of this: https://christine.website/blog/experimental-rilkef-2018-11-3....

Then again, I'm a developer first and foremost, maybe I'd like this better were I a designer.

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

#107

Post by ehnto »

wizzzzzy wrote: post #100
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've used a similar approach in the past but found that having styles for each component also defined in vaious 'contexts' became quite confusing. Using modifier classes defined alongside the component I found to be easier to understand / follow and also improved usability of those those styles across the codebase.

I have been playing with bringing modifiers in for when the context isn't why something gas changed. Like a normal product card and a special product card.

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

#108

Post by chrisweekly »

In terms of applying styles to pages / component hierarchies, I find it useful to think in terms of "global / baseline", "layout", and "utility classes". I wish layout were always viewed as a first-class concern, entirely separate from branding, colors, etc.

I think "Every-Layout" (https://every-layout.dev) makes an extremely compelling case for this approach. I'd love to see an example of a design system leveraging these beautiful, coherent, logically sound typography-based layouts, incorporated w/ modern component architecture, ready to be customized and themed. IMHO that'd be as transformative now as twitter bootstrap was when it first arrived.

Post reply on HN