Published on

CSS works against maintainability


CSS isn't for engineering

CSS was never designed for the maintainability of HTML styling - it goes so far as to actively work against it.

Say my name

As many are hinting at the moment, CSS forces you to name things that would normally be unnamed, i.e. you have to give a globally unique name to the attributes of your components.

The difficulty of naming things does not aid maintainability; the laziness of developers (which is counterintuitively what makes them productive and inventive) works against this. In the absence of other ideas, the tend to reflect the developer's hierarchy in the DOM, which makes it hard to refactor the components without also rewriting and renaming the CSS classes.

Never tear us apart

CSS forces you by design to separate your styling from your components, requiring extra discipline from the developer to either collocate styles and HTML pedantically in your filesystem, or name/comment things in a way that makes their mutual relationship obvious.

Joined at the hip

The cascade (at the heart of CSS) creates coupling between unrelated components due to inheritance. Object-Oriented Programming is rightly criticised for the tight coupling between inherited classes, but this is only on definition: CSS goes one step further and couples classes based on their usage.1

And that coupling can happen in multiple locations, with different combinations of classes. Once that’s done, you have brittle, difficult to untangle and modify components.

One more time

CSS instead tried to solve the more obvious problem of maintainability: the repetition of inline styles. But that relates to the idea of HTML being a programming language in itself, something worked on directly for document creation, stemming in part of the purity of the idea of a HTML as a part of a hypertext system, itself a smaller component of a hypermedia system

As developers, we solve the repetition problem through templating, but we don't have that facility at the HTML layer2. As developers we solve this with procedural generation at a higher layer of abstraction (e.g. React, handlebars, etc).

CSS tried to solve the repetition problem without templating, but created a bunch of others inadvertently.

Too many have been led astray by the seductive notion of maintaining the structural purity of HTML, a hypertext free of styling concerns, and something that heavily influenced the design of CSS. The other problems CSS introduces is something developers have only dared to collectively address after years of suffering the use of HTML and CSS as it was designed ("use the platform"), and we still have had to solve outside of it.

Tailwind as panacea

But as a panacea, Tailwind is a really good one. It still suffers from the repetition problem, but we can solve that a higher layer anyway. It avoids the inheritance problem, while still giving access to CSS features that inline styles won’t3.

Unless the platform changes to enable maintainability in it, hypermedia as living medium that both developers can build in and change things in, HTML will always be the output format end of a CI/CD pipeline, instead of at the core of it.


  1. There are some style attributes that are inherited (like font-family or the base size via the font-size value of the <body> tag), but these limited cases seem sensible, and for the better.

  2. You can template with JavaScript in the browser, but that means we serve an incomplete HTML page and rely on the client to "render" the page, causing its own set of problems with SEO and compatibility with non-JS browsers. Web components, as far as I understand, still require JavaScript and don't offer a great fallback solution for browser that don't support them (not that the latter should be a concern)

  3. Why must we suffer the "use the platform" purists, who limit certain styling features to stylesheets? With the almost viral popularity of Tailwind, who is still clinging onto the idea that CSS won?