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

71–80 of 108 posts

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

#71

Post by asjw »

In my opinion the problem is that CSS apply styles and positioning to markup

Components have been a solved problem in desktop apps for decades

You have layout and styles applied to components positioned in the layout

What's really problematic is having a presentation layer that's split in layout and styles in the same context (CSS) while content and structure are both exposed in HTML

If we had layout in HTML and styling in CSS it would be easier to reason about it

HTML was born to give the document structure, layout is in the same league if you ask me, but then styles became the only way to lay out content, HTML lost its purpose of being the way to structure content in a meaningful way so you have the same HTML behaving diffentely with different layouts just because CSS can work on both of them

If footer meant "stuck at the foot of content no matter what the content is" we could have saved a lot of engineering hacks around making it reusable

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

#72

Post by nailer »

This very long article leads to the following point:

---

> Utilities force you to choose:

Is this text-sm or text-xs?

Should I use py-3 or py-4?

Do I want text-dark-soft or text-dark-faint?

You can't just pick any value want; you have to choose from a curated list.

Instead of 380 text colors, you end up with 10 or 12.

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

#73

Post by tqkxzugoaupvwqr »

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:

    export default Vue.extend({
        data() {
            return {
                isActive: false,
            };
        },
        computed: {
            componentClasses() {
                return ["margin-4", "padding-3", {
                    "color-red": this.isActive,
                    "font-size-30": this.isActive,
                    "font-weight-700": this.isActive,
                }];
            }
        }
    });

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

#74

Post by underwater »

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…

Writing code to transform arbitrary XML/HTML trees to a layout is really hard. Naive solutions tend to break down as soon as you get weirdly structured trees. Expressing "Handle nodes like this unless there is a child with class 'foo', or we are descended from a

with class 'bar'" in imperative code is hard.

I've worked on a moderately complex codebase that did something like this and it took a long time to get to a place where new feature requests didn't end up introducing additional complexity and the codebase wasn't a big ball of mud.

For all CSS's faults, most developers can still ship code that is understandable.

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

#75

Post by erikschoster »

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…

Add a class called "active" or similar, and write your css to target the element when that class is present.

    .element.active {
        color: red;
        font-size: 30px;
        font-weight: 700;
    }

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

#76

Post by sonofhans »

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 systems. In a well-structured Drupal or Wordpress site, for instance, you can link to one additional stylesheet and override any aspect of the design. Some of the CSS might be ugly, and every now and then you might need the HTML tweaked to add a class, but it works.

Check out [http://www.csszengarden.com]. This is an old site, nearly 20 years old, put up by designer Dave Shea precisely to disprove your point :) It sports hundreds of interesting designs with non-trivial layouts, really pushing the boundaries of what was possible back in the day. All of the designs are CSS-only, and hang off the same HTML skeleton. If you view the source, it's pretty simple.

Doing this with JavaScript introduces all sorts of other concerns: accessibility, security, privacy, maintainability, future-proofness, compute necessary to render, render time, etc. jQuery did basically this, right? Selecting markup and content with CSS syntax to munge them, or attach triggers.

I rarely see people write vanilla CSS these days. Most folks abstract it with SCSS or LESS. That removes a lot of the warts. It's still too easy to end up with 5000 lines of CSS that can only be tested by manual inspection :/

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

#77

Post by aliveupstairs »

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…

> (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 style it in an arbitrary way.)

I think that's a different issue that has to do with the web not having proper layout tools. Where in order to position a group of elements, you had to div them. Nowadays, we have `align-self` and `display: contents`.

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

#78

Post by tannhaeuser »

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

As an aside, XSLT 1.0, based on DSSSL and created by its author (as is groff and SP SGML), is 20 years old to the date.

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

#79

Post by andrethegiant »

mmckelvy wrote: post #70

CSS felt "solved" for me when the React team introduced inline styles. I've been using them ever since and it has made styling a breeze. I know people balk at inline styles, but I still haven't heard a convincing argument as to why they are a bad thing.

Lots of rule duplication and no pseudo-selector support with inline styles. If you like using inline styles, I think you'd like CSS-in-JS, because it has a similar feel when writing components with the benefit of deduped atomic classes as critical CSS + pseudo-selector support.

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

#80

Post by andrethegiant »

jameslk wrote: post #44

Maintenance of these utility class CSS codebases is such a pain. I've had the pleasure of dealing with it. What if you want to tweak one of your utility classes ever so slightly? If your codebase is big enough, you've just created enormous amounts of potential regressions.

This is why CSS-in-JS solutions outshine utility classes IMO – if you deal with stylesheets directly, it's hard to avoid treating CSS as append-only files that grow linearly with the size of your codebase. With CSS-in-JS, on the other hand, the styles get generated for you, at a size that grows logarithmically to the size of your codebase (style rules of the same value get pulled into their own deduped classes).
Post reply on HN