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

61–70 of 108 posts

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

#61

Post by tln »

csande17 wrote: post #22
1_player wrote: post #17

Earlier quoted context omitted.

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.

I've found that using the same class name for styling and attaching behaviors to be dangerous... refactor the styling and lose the functionality, or break the tests, or disable the analytics.

I'm glad that backbone and jQuery apps are in my rear view mirror at this point.

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

#62

Post by chrisweekly »

koboll wrote: post #34
chrisweekly wrote: post #28

Earlier quoted context omitted.

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.

upvoted and agreed

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

#64

Post by deltron3030 »

circlingthesun wrote: post #24

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/

Yeah, it's technically better than Tailwind CSS, but unfortunately JS/React only.

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

#65

Post by meerita »

Izkata wrote: post #60
meerita wrote: post #46

Earlier quoted context omitted.

Give me an example of that. Would you mantain .display--block? how? .color--red?

Changing the saturation of the red and causing it to look messy alongside surrounding elements/images? Or introducing colorblindness concerns elsewhere in the app?

That means two things: you need extra utitilies to have different reds or, you don't mind to adjust the same red that will impact in the rest of the website. As a designer I do this all the time. If my design is complex to the point I would need several reds, then i would use a different value in the class name, like numbers or other options.

Then my workflow for that case would be: create the new color value, compile the CSS, change the class name in those places where I want to use the new red.

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

#66

Post by IggleSniggle »

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?

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

#67

Post by IggleSniggle »

LaMarseillaise wrote: post #54
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 think one of the major advantages of Web Components is that styles can be isolated without the need for name-spacing. There is no need to carefully structure CSS according to the DOM, because this isolation is included with the shadow DOM. Incorporating CSS grid takes this even further, allowing these isolated designs to be responsive to the layout without needing to know what it is.

Absolutely agree. My only gripe is that consuming a blackbox (ie third party) Web Component inside a Web Component can get problematic. Your options become create a global override system or (shudder) Shadow DOM piercing.

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

#68

Post by adamwathan »

Author here — a common question I’ve seen in the comments that I didn’t cover in the article is how you do responsive design with this approach.

Here’s a link to the responsive design guide in the Tailwind CSS docs that covers it in detail:

https://tailwindcss.com/docs/responsive-design

The TL;DR is you have breakpoint-specific versions of your utilities, so you can define all of your responsive behaviour directly in your markup.

For example this element would be `block` by default (on mobile) and `flex` when the browser is at or above some defined “medium” breakpoint:

Two years after writing that article I can say CSS definitely feels “solved” to me, and every time I have to go back to an old Tailwind project it’s very easy to make changes.

If you’re building things with React, I’d also encourage you to explore projects like Emotion and Theme UI which allow you to work with the same philosophical approach (styling elements directly instead of through “hooks” and some separate style layer) but with a bunch of neat advantages that aren’t possible with a regular class/CSS-based API, like having better control over how style definitions override each other when applied to the same element.

Personally I’m still very happy using Tailwind even in React projects, because the syntax is more terse and it’s nice to have a singular styling paradigm that I can use even outside React projects.

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

#69

Post by inopinatus »

Andrex wrote: post #3

The money quote for me: "The reason I call the approach I take to CSS utility-first is because I try to build everything I can out of utilities, and only extract repeating patterns as they emerge." I've been puzzling over the same "Separation of Concerns vs. Mixing Concerns" dichotomy ever since the rise of Bootstrap. Something about using Bootstrap's classes never felt right to me, but I was never happy with the amo…

Two decades ago I was overjoyed to discover that Scheme was finally going to have a useful application beyond illustrating SICP and writing koans to amuse myself, because DSSSL was on the cusp of evolving into the last document styling language anyone would ever need.

Unfortunately following an incident with a broken Lisp machine, a liquid lunch, and an unlicensed particle accelerator, I became trapped in a parallel universe where the HTML ERB anointed CSS by mistake during a drunken night out in Oslo.

The fundamental concept of CSS (best revealed by H.W.Lie's thesis IMO[1]) was to create a rich and versatile and non-Turing-complete set of structural selectors in lieu of DSSSL's recursive logic, and to allow styles to overlay one another; two design choices that only by the application of gallons of irony can explain why most web pages are composed of a bunch of nested DIV elements with hashed IDs and overloaded semantic class attributes, and everyone compiles their assets into a static file.

I switched to Tailwind CSS months ago. Adam Wathan is the hero we deserve.

[1] https://www.wiumlie.no/2006/phd/css.pdf

Post reply on HN