This is why you hate CSS (and what you can do about it)

Published on 01.04.2020 by Peter Kröner

You know how it goes: your heroic attempt to change the color of something in the top left of your web page not only fails to change the color, but something entirely unrelated in the footer turns green instead. Seen through the fog of your frustration it may appear like CSS is broken, but it is actually working just fine. What looks like a major flaw in CSS is really a feature  and at the same time it is sort of a flaw that anyone working on web frontends has to come to grips with.

Almost every CSS file is a bag of contradictory rules that all overwrite each other many times over. No CSS rule in such a file can be viewed on its own and chaos is almost guaranteed to ensue. Consider the following example:

footer p {
  color: green;
}
strong {
  color: blue;
}
p {
  color: red !important;
}

If you are somewhat CSS-savy you can predict what the color of a <strong> element inside a <p> inside a <footer> is going to be, but the answer is far from obvious, even in an example as simple as this! Why does CSS have to be such a contradictory mess?

CSS looks simple, but it seldom is.

To explain why CSS is the way it is and why it is never going to get “fixed” we need to consider that web languages do not work like most other technologies around us. They act more like giant organisms and are subject to evolutionary pressures that the environment exerts.

Back in the day, when web design was yet to become a thing, it was not clear at all that web design as we know it today should even be a thing! Many proposals for an official style sheet languages circulated across mailing lists, but the most contentious issue was neither syntax nor semantics: it was about who gets to set the styles in the first place. Authors of web pages wanted to control the look and feel of their works, but not all users were convinced that this would be a good idea. Many would rather configure the way web documents render in their browsers by themselves. And so the winner of the early Style Sheet Wars could only be a contestant that offered a compromise. To quote A brief history of CSS:

But, CSS had one feature that distinguished it from all the other [style sheet languages]: It took into account that on the Web, the style of a document couldn't be designed by either the author or the reader on their own, but that their wishes had to be combined, or cascaded, in some way [...]

Other proposed style sheet languages had more advanced features than CSS (like variables and nested style rules), but the cascade was the only true killer feature at that time. The contradictory mess of endless style rules all overwriting each other is the whole point of CSS  but at the same time many a frontend project's downfall. There is no way you can look at an individual CSS rule in isolation and predict its effect on the whole web page. It is just impossible by design. And this turns into a substantial problem once you have a large team working on a project with CSS in it. If there is just one large style sheet that everybody just adds to, CSS spirals out of control rather quickly.

So this is how it is: our core technology for describing the look and feel of a web project has arrived at not quite a dead end, but has merged into a one-way lane. There is no alternative in sight and our projects get more and more complex, turning the trade-offs inherent to CSS from a feature into a scourge. But this does not mean that we are totally screwed, there is still something that can be done: If the technology can't change anymore, our relationship to the technology must change! By adjusting the way we use it, we can eliminate the effects many of the less-useful parts of CSS from our minds and projects without changing the language itself.

There are four simple steps that you can take to ease your CSS-related pain. Some of them may look obvious to you, but a surprising number of companies and developers do not even try to follow rules of working with CSS in 2020:

  1. We must take CSS seriously and stop carelessly writing CSS like its 1996. We have to put some measure of effort into making CSS work the world of 2020.
  2. This effort starts with picking (and sticking to) a CSS methodology, any methodology! Smart folks with decades of experience have devised rules to structure your CSS. Imagine that  deliberate structures in CSS! They all boil down to the same simple principle: don't just add rules and declarations to your existing CSS, but think before you write. Every methodology comes with names for concepts and naming conventions for CSS selectors, which improve communication within your team by leaps and bounds. You can pick any CSS methodology you like, as long as it is more refined than “just add stuff until to looks right”. I personally like BEM because it is easy to explain and, because of its naming conventions and simple rules, easy to enforce.
  3. Once you pick a way to write CSS you must define what's “right” with a pattern library. If the team that works on your CSS consists or more than one person, it is imperative to nail down how elements and components are supposed to look, or else you won't even be able to tell if your design has gotten out of whack. This definition of the single source of truth must be an interactive web document, a PDF or a PSD file does not cut it. Your production web page is full of interactive elements (even humble <a> elements may have up to 23 different states when pseudo classes like :link, :visited and :hover and friends are taken into account) and the pattern library must reflect this. It does not matter which tool you use to generate your pattern library, or if you choose to hand-craft it from scratch, as long as the end result is HTML and CSS.
  4. And of course there's every web developers favorite approach to problem-solving: throw tools at the problem until the problem's impact has diminished to a tolerable degree. It sounds like a joke, but it works! Just think of the way frameworks, linters and even more advanced tools like TypeScript have transformed JavaScript from something considered to be a joke (remember the WAT video?) into a respected programming language.

Regarding the last item on the list, this post is of course a thinly veiled plug for Warhol, which is one of the tools that you can throw at the problem of out-of-control CSS. But the real message of this article is more substantial than advertising for a great and affordable SAAS that will help you to find design bugs on your production web page in mere seconds - the real message is that it is not 1996 anymore and we can't expect CSS to neatly fit into the world of 2020. Our approach to dealing with CSS must change because CSS itself will never truly change.

Written by

Peter Kröner

Trainer for frontend technologies, podcaster @workingdraft.

Twitter

More from the blog

Be the first to know

You want to know more? Stay tuned and subscribe to our mailing list. We keep you posted of the progress of Warhol.