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

91–100 of 108 posts

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

#91

Post by james_s_tayler »

listenallyall wrote: post #25

(Article is from 2017). TailwindCSS is a terrific library. One area that wasn't covered was the ease of creating truly responsive layouts, inline, by defining different utility classes to the same elements based on screen size. "Responsive" is so much more than just the placement -- quite often, mobile version needs different font sizes, overflow behavior, thinner margins (since there is less screen space), etc. Very…

I find Bulma strikes the right balance in this regard. It feels like bootstrap, only much cleaner, but then it also has these nice responsive classes you can apply. It makes it very, very easy work with.

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

#92

Post by _9hey »

I wanted to point out some of the downfalls of utility classes, but then realized that my main objections are with the HTML-CSS model itself. Adam was, as we all are, trying to make the best of this weird web dev situation. It is the discussion itself that is the most valuable imo.

Architecture is not a striving toward perfection, it's a collaborative process of finding heuristics that give good results based on real-world constraints.

Things to consider:

Utility classes do not do well when there are multiple states involved (as a simple case, consider :hover). Libraries that use the CSS utility classes do not follow the "Open-closed principle" or the "Dependency Inversion Principle" – depending on the mental model you use.

The term "functional CSS" is a misnomer, since the composition of styles happens at the HTML layer. Calling it "mashup CSS" would be far more accurate.

One huge problem in writing any software is figuring out how to make good decisions about where and how to compose smaller building blocks into bigger ones. Category Theory helps with many of these questions, but is far from sufficient to answer all of our questions. So it's quite valuable to discuss and try new things.

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

#93

Post by ellyagg »

sonofhans wrote: post #76
ken wrote: post #40

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…

I agree with you that CSS is weak, especially from today's POV, and that HTML & CSS can be unwieldy together. Also that "It's rarely possible to use some random HTML and style it in an arbitrary way." However it's not true that "can't make a nice structure in HTML, and then style it with CSS." That is one of the design goals of CSS, and it works. In a former life I did this for many years, with many CMS and front-end…

You can re-style arbitrary (or well-designed) HTML in lots of different and cool ways with CSS. But you can't re-style it to the new particular design that management wants.

And even if I'm wrong, the last decade has proven that your regular above-average developer can't typically do it, and that amounts to the same thing.

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

#94

Post by mcgwiz »

What's always missing from these perennial CSS deep dives is that HTML already gives us a paradigm worth extending: generic constructs, used in domain specific contexts. Generic constructs are those that are devoid of domain specifics and can be used by HTML documents from other domains, e.g. links, paragraphs, buttons, tabs, and modals.

A link can refer to a user profile page or a news article. Both use the generic anchor "component", which comes from the wider universe of components applicable to most/all HTML docs. HTML: ``, CSS selector: `A.user`.

To extend this, a media card could represent a video or a book or a sidebar item. Both use the media card component's HTML structure but can be tweaked visually with CSS. The root element of the video media card would be `` and would be identified with the selector `DIV.MediaCard.video`.

(PascalCase is arbitrary but I like that it harks to class naming conventions from OOP languages. You'd need some other naming conventions as well. I like `_title` for internal element class names, like private class members from OOP languages. Internal selectors would be built using the performant child combinator. Some of these patterns are more verbose than current alternatives, but it's also the minimum necessary to get crystal clarity around inherited and cascaded values. Preprocessor nesting makes this less painful. And `-highlight` for variants, because they resemble CLI switches. What about non-generic components? Those aren't "components" as defined here - they are simply higher-level HTML fragments, typically organized in source as an HTML template.)

This gives you two dimensions along which to flexibly organize things - the generic forms and the domain-specific applications, and should keep you from slipping down the slope to utility-dominant CSS.

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

#95

Post by 38932ur98u »

adamwathan wrote: post #68

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…

Thanks for the fantastic library! I've really enjoyed using it and it has sped up dev time phenomenally. However, I am curious: what is it like using tailwind on huge projects? I can imagine with many developers working on a codebase the "extract repeated patterns to their own new class" philosophy can get easily ignored, or difficult to track where some series of classes is being repeated.

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

#96

Post by frenchy »

tln wrote: post #61
csande17 wrote: post #22

Earlier quoted context omitted.

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.

The reason why you're finding this dangerous is because you've coupled your class names too closely with your style. Class names should describe what the content is about, and so if the class names change, that implies that the content itself is different.

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

#97

Post by ehnto »

karaterobot wrote: post #88
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…

> I didn't know there was a name for this method

I just made that one up when I started formalizing the method!

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

I find as well that if you write clean, concise CSS that doesn't have to override anything you get away with far less CSS anyway. So repeating yourself isn't so bad. Similarly, in a project of any longevity, especially if clients are involved, chances are pretty high the things you repeated will eventually diverge. So had you made it DRY you would have to de-compose the coupled components and write it again anyway. With the Contexts, you can make most diverging modifications without ever touching the components, and I feel any more levels of inheritance than that leads to CSS that is more complex than it needs to be.

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

#98

Post by malydok »

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…

Wouldn't it be possible to do: `["margin-4", "padding-3", ...(this.isActive ? ["color-red", "font-size-30", "font-weight-700"] : [])]`

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

#99

Post by sdnguyen90 »

I’ve been using utility classes for a few years now. Some thoughts I’ve come up with:

For content heavy sites like ecommerce/marketing/blogs, I use pretty much utility classes exclusively. There usually isn’t much reuse of UI components on these types of sites so maintenance is much simpler compared to semantic classes. With semantic classes you’ll have a lot of one off styles.

I actually really enjoy writing sites like these since I can code a site start to finish without touching any CSS files. Using utility classes I probably finish 25%-50% faster than if I were to use semantic classes.

On more web app type things like admin panels, I use a mix of mostly semantic classes and a few utility classes. I only use utilities to make sure there aren’t a million different padding/margin/font size values.

In the earlier days of React I tried using all utility classes and it just felt like there was too much going on in the JSX. If you use utility classes, you know the class attribute can get pretty long - sometimes needing to be broken into 2 lines. The CSS tooling with Webpack has come a long way and solves a lot of the problems that all the utility class frameworks were trying to solve around 2015.

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

#100

Post by wizzzzzy »

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