CSS Classes Considered Harmful | Hacker News Reader

CSS Classes Considered Harmful

keithcirkel.co.uk

12 pointsKeithamus24 comments

CSS classes are great at what they're designed for. I don't see the problem.

If you're afraid some random other CSS may come in and ruin your existing classes, you've got other problems. In Javascript I can override random functions in prototypes and leave you to deal with it, but that doesn't mean you should program as if I might.

I've become accustomed to writing SCSS rather than CSS to make generating properly scoped components easier. It saves a lot of declarative repetition when all I want is to style the first and last spans of a div tagged with a certain class while also styling the other components inside the div. I know there are many advanced features in CSS generation libraries but this is all I really care about.

I'm a strict believer in separation of concerns on the web. Not just because it produces cleaner code, but also because it makes custom user styles easier to accomplish.

That said, custom tags are an elegant solution I haven't really considered yet. I found out about them when I couldn't really rely on browsers supporting them and have ignored them ever since. I think they're probably the best of both worlds, though I expect many HTML generation libraries to choke on them.

For large applications with many thousands of pages, or many thousands of engineers working on the same system, name collisions happen. It’s not just throwing “random css” into the mix, it’s that many disjointed parts of the same application suddenly become connected and interdependent. Especially with “parameter names” like “size”. You really have three choices to solve this: invent elaborate tooling to catch overuse; prepend your classes in the hope that lowers conflicts; or over specify selectors and deal with the specificity issues that fall out from this.

Custom elements are very well supported today! I’d encourage you to spend more time with them!

Wish this article dedicated time to considering whether widespread use of attribute selectors will slow down the browser, but it doesn't seem to. CSS class selectors have been aggressively optimized by browser vendors for decades, vs. selectors that just filter on an arbitrary set of HTML attributes.

Modern devices are pretty fast though, so maybe it's not an issue - but I know in the past the cost of doing CSS rule evaluation has been a problem.

We use this approach, and I've wondered the same thing. The only evidence I found where it's slow is in old versions of IE. Haven't tested it myself except anecdotally, but we've had no problems with them.

I considered exploring it but css selector performance just doesn’t matter with todays engines. There are far greater issues, and far better performance wins than “optimising your selectors”.

Makes sense, I would just worry that if I built my whole stack around this, suddenly I hit a breakdown point where I have a ton of attribute selectors and now adding new DOM elements to a content view takes a millisecond.

I'm more wary about this than I used to be since someone managed to accidentally cause tsc to need multiple seconds to compile a single file by making a small change to a type definition. Big O still can bite you!

The problem they describe is nonexistent. They say <div class="card big"> is bad because

    some other CSS can come along
    and co-opt what big means

Doesn't matter, because you would not style ".big" but ".card.big".

Yes, if someone would redefine "card", that would be a problem. That's why this "base class" should not be as short as just "card" but rather "userInfoCard" or something like that.

> The problem [he] describe[s] is nonexistent. [He] say[s] <div class="card big"> is bad because

    some other CSS can come along
    and co-opt what big means

To me the complaint is like saying, when programming, that I shouldn’t define functions with names in a file that’s imported into another file, because “some other” file can “come along” and redefine those names. If that’s a problem then that’s your problem, not the existence of classes. Or names.

Naming collisions are a pretty real problem when you get to building large systems. They’re a big enough problem for something like CSS Modules to exist (explained further down in the post).

After reading the article I found not a single indication, at all, of CSS classes actually being harmful. But the allusion of the headline worked, and I clicked.

I felt the “considered harmful” style of titles have been overused that no one would reasonably consider it anything but click bait; and so used it as ironic-click-bait.

Right. It's a tired trope at this point. Sort of like "disrupting" this or that business segment.

The article did a good job of explaining the problem of codifying a style ontology using only clases, and proposing a solution to that problem (custom attributes and pseudo selectors for specialization). It did not convince me that classes themselves were bad, and replacing them with custom tags doesn’t seem to solve anything. The main argument advanced against classes (as opposed to certain ways of using classes) seems to be that they are old tech, which doesn’t make much sense to me. Did I miss something?

The main problem (as described) is that CSS classes don't take parameters. Imagine coding in Foolang and its classes don't take parameters, resulting in class explosion.

Author goes on to show how to give them parameters, news at 11. ;-)

CSS suffers from the lack of composability and organizational features found in modern high level programming languages. If your excited about modern css features like "is" or "has", then you agree it needs more functions to keep up with customer demand.

I wrote a bit about this problem from the perspective of a clojure and clojurescript developer on my blog. https://drewverlee.github.io/posts-output/2021-8-26-css-opti...

The reason, clojure and clojurescript is relevant is those programming languages can easily compile to css, allowing users to easily add pl features that don't exist in css and not force devs to learn the same concepts twice. It can do this becuase as a lisp, turning clojure native hashmaps into classes (or attributes if you prefer) is like pouring water into a container. We numerous libs to do this in the clojure ecosystem, here is a reddit discussion around the newest one: https://www.reddit.com/r/Clojure/comments/w56tg8/shadowcss_c...

Though i would personally opt for the slower page perf and faster dev performance of just using cljs compiled to inline-styles solution, as i suggest in my blog.

Of course there might be performance benefits to coding at the lower css level directly, but on average that's not a good tradeoff for most teams i have worked on. s

A catalogue of errors one can implement with CSS classes (as easily as using other CSS selectors) and of bad solutions to nonexistent problems.

On top of that, a strange attitude: apart from the embarrassing argument that "old" technology is bad, the author assumes that HTML is written by hand, apparently by a team of monkeys taking pride in the intensity of their fuzz testing, rather than generated correctly from templates.

Hence the emphasis on defensive coding and on treating easily fixed mistakes as a disaster (as if web developers routinely edited pages in production without testing).

I don’t recall saying old technology is bad. I was more trying to say it served its purpose at the time but as websites have gotten more complex we’re still relying on this one single primitive.

It’s true that as systems scale often templating systems are introduced to alleviate writing html, but these systems are rarely complete which means developers - meeds unmet - need to “drop down a layer” and in that should be set up for success not failure. Having a design system that use brittle underlying primitives will not set developers up for success.

Great article. Shouldn't have been flagged; I think a few folks pride was hurt.

However, there's a foot-gun in the first paragraph. In the mid-nineties practically no one was using "black and white" monitors. I remember a few ancient DOS test-only stations at a school and a single amber-monochrome hardware terminal (connected to big-iron at work) in that time period. Everything else doing real work was Win3.1 and color Mac by then. Netscape browser had already dropped and was popular; no one was using it in black and white.

This was in California. May be slightly ahead, and I'm not taking developing countries into account. But color was so compelling it was already not-uncommon by the late 80s.

Was a poor attempt at a joke that perhaps didn’t carry :p

Sounds like you're heavily invested. I found the piece interesting. CSS is far from perfect and could definitely use a rethinking once in a while.

Yet another example of how all articles titled ___ considered harmful are nothing more than clickbait.

I appreciate the ingenuity of the solution. But I still prefer Tailwind-esque style of css styling.

So...the problem with css classes is that they are old? I'm not sure I quite understand the why.

Data-attributes on html elements are only for JS behavior in my usage, and CSS classes are for styling.

No, it's because they don't take parameters. Parameters are supported in the tag itself however, might as well use them.

Reply on news.ycombinator.com