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

11–20 of 108 posts

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

#11

Post by csande17 »

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.

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

#12

Post by cousin_it »

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.

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

#14

Post by madoublet »

Adam is an awesome follow on Twitter. I still haven't come around to his way of thinking on utility classes. It feels messy compared to a component based approach. But, I totally respect his work and can see myself adopting something like this in the future.

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

#15

Post by ChrisMarshallNY »

ChrisMarshallNY wrote: post #9

I've been writing sites like this for years. It can look sloppy, but I find that it's important to provide as many "hooks" as possible to elements; especially dynamically-generated elements. This is because I've written tools that were meant to be integrated into sites, as opposed to the end site, itself. It was important that the user of the tool be able to exert as much control as possible over the rendering. It do…

Also, for anyone that cares, I wrote up a series on CSS-based Web design about ten years ago: https://littlegreenviper.com/series/cssdesign/

It's dated, but still absolutely relevant.

Here's the start of the specificity section, which goes on for some time: https://littlegreenviper.com/miscellany/stylist/introduction...

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

#16

Post by csande17 »

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 accessibility, usability, or aesthetic concerns.

If all your elements have class names like "mt-2 bg-black font-semibold text-white pt-2 pb-3 flex justify-left", you're making it a lot harder for you, your users, and your co-workers to take advantage of this ecosystem. At the very least, you might want to consider also putting semantic classes on your elements.

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

#17

Post by 1_player »

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.

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

#18

Post by danpeddle »

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?

Placeholders maybe? https://sass-lang.com/documentation/style-rules/placeholder-...

I use these a bit when I’m being more thoughtful, it’s a nice way to think about creating chunks of style that don’t get included in the output, bit surprised they weren’t mentioned yet.

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

#19

Post by XCSme »

> 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 amazing thing about this is that before you know it, you can build entirely new UI components without writing any new CSS.

So, if you want a responsive/mobile version you would have to either serve a different HTML for mobile or also have all the CSS rules for mobile in the inline class names. Before you know, you have a list of 30 cryptic CSS classes written inside the HTML markup for an element.

> How many times have you needed to style some HTML and thought, "this text needs to be a little darker," then reached for the darken() function to tweak some base $text-color?

Well, why not just use $text-color--darker? Define your swatches globally beforehand and do not allow the creation of new colors anyhwere else in the code. I guess his solution is similar, but with using another CSS class instead of a variable.

Also, what if at some point you decide to redesign your site and change the margin of all text? So you would have to replace all "mar-6" with "mar-12", but only where the margin is for text. This looks like a complex update invloving a lot of bug-prone search and replace. If it was written as ".text-margin { margin: 6px; }" then it was just a matter of changing one number and you know it would only affect the text-related margin. Sharing style across components is not always a good thing, it makes changing things much harder. I guess with this approach you should never change the initial values, as the entire design might be affected in weird ways.

I am not saying this is completely bad, I am just saying there's no perfect way of doing things and everyone and every project is different.

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

#20

Post by XCSme »

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?
Post reply on HN