CSS Classes Considered Harmful

CSS classes are great at what they&#x27;re designed for. I don&#x27;t see the problem.<p>If you&#x27;re afraid some random other CSS may come in and ruin your existing classes, you&#x27;ve got other problems. In Javascript I can override random functions in prototypes and leave you to deal with it, but that doesn&#x27;t mean you should program as if I might.<p>I&#x27;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.<p>I&#x27;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.<p>That said, custom tags are an elegant solution I haven&#x27;t really considered yet. I found out about them when I couldn&#x27;t really rely on browsers supporting them and have ignored them ever since. I think they&#x27;re probably the best of both worlds, though I expect many HTML generation libraries to choke on them.

Wish this article dedicated time to considering whether widespread use of attribute selectors will slow down the browser, but it doesn&#x27;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.<p>Modern devices are pretty fast though, so maybe it&#x27;s not an issue - but I know in the past the cost of doing CSS rule evaluation has been a problem.

The problem they describe is nonexistent. They say &lt;div class=&quot;card big&quot;&gt; is bad because<p><pre><code> some other CSS can come along and co-opt what big means </code></pre> Doesn&#x27;t matter, because you would not style &quot;.big&quot; but &quot;.card.big&quot;.<p>Yes, if someone would redefine &quot;card&quot;, that would be a problem. That&#x27;s why this &quot;base class&quot; should not be as short as just &quot;card&quot; but rather &quot;userInfoCard&quot; or something like that.

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.

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?

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 &quot;is&quot; or &quot;has&quot;, then you agree it needs more functions to keep up with customer demand.<p>I wrote a bit about this problem from the perspective of a clojure and clojurescript developer on my blog. <a href="https:&#x2F;&#x2F;drewverlee.github.io&#x2F;posts-output&#x2F;2021-8-26-css-optimizations" rel="nofollow">https:&#x2F;&#x2F;drewverlee.github.io&#x2F;posts-output&#x2F;2021-8-26-css-opti...</a><p>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&#x27;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: <a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;Clojure&#x2F;comments&#x2F;w56tg8&#x2F;shadowcss_cssincljs&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;Clojure&#x2F;comments&#x2F;w56tg8&#x2F;shadowcss_c...</a><p>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.<p>Of course there might be performance benefits to coding at the lower css level directly, but on average that&#x27;s not a good tradeoff for most teams i have worked on. s

A catalogue of errors one can <i>implement</i> with CSS classes (as easily as using other CSS selectors) and of bad solutions to nonexistent problems.<p>On top of that, a strange attitude: apart from the embarrassing argument that &quot;old&quot; 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.<p>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).

Yet another example of how all articles titled <i>___ considered harmful</i> 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&#x27;m not sure I quite understand the <i>why</i>.<p>Data-attributes on html elements are only for JS behavior in my usage, and CSS classes are for styling.