Skip to content

About the author of Daydream Drift

Tomasz Niezgoda (LinkedIn/tomaszniezgoda & GitHub/tniezg) is the author of this blog. It contains original content written with care.

Please link back to this website when referencing any of the materials.

Author:

Responsibly Striving For Semantic CSS

Published

Software developers know that naming variables in source code is hard. This also applies to CSS classes and IDs. Ideally, everything would be named semantically and self-described so that comments and documentation could be skipped. It's not easy or even possible in reality, though.

Reasons why:

  1. Non-semantic CSS is occasionally used for referencing HTML, the same way as HTML's data- attributes are. This sort of metadata is useful for tasks like automated testing. For instance, I was asked by other teams on occasion to "provide" extra identifiers in HTML allowing them to test my team's project. How we went about it was up to my team. Having these identifiers separate from the rest of the code and simple, like .e2e-testing--next-button makes them stand out and more resistant to changes in the project. They can also be changed without influencing the rest of the project. And in many cases, what needs referencing in a test doesn't need a class for anything else. So, using identifiers specifically for testing makes code easier to work on and think about.
  2. Non-semantic CSS can vastly simplify source code. Therefore, I'm not at all surprised libraries such as Tailwind are so popular. Technically, Tailwind's classes follow CSS styles quite closely. It's a thin facade on top of CSS. Even so, using Tailwind's classes such as mb-3 instead of writing margin-bottom: 0.75rem adds up to significant savings in a larger project. mb-3 is not semantic. It doesn't describe the purpose of the element it's styling. And yet, it is useful. It could be injected into a semantic class, of course. But it's not always productive to do so as elaborated next.
  3. Semantic classes, as much as devs would like them to, don't often last much longer than non-semantic classes. Having worked on dozens of web projects I can confidently say spending too much time mulling over CSS names is wasteful. Slightly more worth it in libraries (like Tailwind). Front-end follows and should follow the needs of the users. If improving UX requires removing a bunch of HTML, JS, and those nice CSS classes the team spent time inventing, companies don't think twice about doing that. It's barely a question. I have never even raised this issue with business on any project.
  4. Non-semantic CSS fits nicely as "configuration" for semantic CSS. Let's say there's a styled React component called CreditCardEntry. It could have non-semantic CSS applied to be reusable in various layouts housing it. For example, a sidebar or a modal window of a website. This way, the component itself doesn't have to implement the different style variants. It just obeys the non-semantic styling enforced by its surroundings.

There's value in having semantic class names in CSS. But going overboard with them is misguided. I find it analogous to overusing functional programming in JS or deduplicating code simply due to it repeating. There's a time and place for everything.