HTML, CSS, and Dependency Direction

Published on February 14, 2018 (↻ October 3, 2023), filed under Development (RSS feed for all categories).

Adam Wathan wrote one of the most interesting web development articles I’ve read in the last few months: CSS Utility Classes and “Separation of Concerns.” At least until “Phase 3” there’s much to learn about current web development, when then, we drift into one of the two extremes and may still have other options to consider.

What I wish to do here is not critique the ending of this otherwise instructive article, but to look at one great aspect, dependency direction:

[…] think about dependency direction.

There are two ways you can write HTML and CSS:

1. “Separation of Concerns.” CSS that depends on HTML.

   Naming your classes based on your content (like .author-bio) treats your HTML as a dependency of your CSS.

   The HTML is independent; it doesn’t care how you make it look, it just exposes hooks like .author-bio that the HTML controls.

   Your CSS on the other hand is not independent; it needs to know what classes your HTML has decided to expose, and it needs to target those classes to style the HTML.

   In this model, your HTML is restyleable, but your CSS is not reusable.

2. “Mixing Concerns.” HTML that depends on CSS.

   Naming your classes in a content-agnostic way after the repeating patterns in your UI (like .media-card) treats your CSS as a dependency of your HTML.

   The CSS is independent; it doesn’t care what content it’s being applied to, it just exposes a set of building blocks that you can apply to your markup.

   Your HTML is not independent; it’s making use of classes that have been provided by the CSS, and it needs to know what classes exist so that it [combines] them however it needs to to achieve the desired design.

   In this model, your CSS is reusable, but your HTML is not restyleable.

This is useful. Dependency direction is a great way to think about the link between HTML and CSS.

But.

(That’s not to say dependency direction was not a great way to think about the link between HTML and CSS.)

But:

There are two issues with this.

One is that there still is no 1:1 relationship between HTML and CSS.

Two is that we still benefit from looking at the situation with an eye on long-term maintenance.

The Relationship Between HTML and CSS

The relationship between HTML and CSS has changed over time and it’s contingent on the type of site or app.

Period or Type	HTML	CSS
90’s	n	0
2000’s	n	1 to n
2010’s	n	1
2020’s	1?	1
Multi-domain, multi-client sites	n	n
One-pagers	1	1

What this generalized, simplified, opinionated table aims to show is that yes, we seem to be heading to a 1:1 relationship between HTML and CSS—as in one template, one style sheet—but no, so far the only use case where we’ve actually seen this is the classical one-pager.

What that means for dependency direction is that maintaining the “higher” side is more expensive, and that therefore, in every case but the one-pager, more work goes into maintaining HTML.

Intuitively, we all know this: On the one-pager extreme, clearly it doesn’t matter how badly we mess up either HTML or CSS. It’s pretty simple to work with one-pagers. On the other hand, with a complex website, to this day is there a magnitude of difference between performing HTML and CSS changes—one, CSS edits, “goes really fast” (and in this complex environment sometimes wrong), the other, HTML updates, often consists of searching the entire code base and partnering up with other teams.

We may well talk dependency direction but we wouldn’t be smart if we ignored that in one case, we need to update one style sheet, and in another, we need to update ten thousand documents or twenty template files. (That is the motivation for good maintainability, and something that drives my own maintainability research.)

The Situation With Long-Term Maintenance

In general, web design is a process. It is well possible (this site is one in a long history of cases) to extend and grow and improve a website (and also an app) just through iterations.

Then, however, a full redo and relaunch is still always on the table; in the best case because of a strategic re-orientation that requires to design and code anew; in the worst case because of severe mistakes, whether through inexperience and incompetence or through short-term thinking, like “fire and forget.” (I’m working on my harshness.)

What does the generally useful concept of dependency direction have to do with this?

A suspicion, I admit.

The suspicion that we don’t know.

The suspicion that we don’t have any reliable data to tell what difference HTML ← CSS (HTML depending on CSS) and CSS ← HTML (CSS depending on HTML) make, in the long run.

The suspicion that the relationship between HTML and CSS is and remains n:1, and that thus, CSS ← HTML, and that thus, long-term, it’s better to stick with best practices around focusing on the HTML and being careful when admitting (legitimate) exceptions.

And yet this is a suspicion—we need more data, at least some well-documented empirical accounts (yes, I said this), in order to get a sense of direction here.

❧ Overall, dependency direction is useful to think of. Alas, by itself it doesn’t mean anything if we don’t look closely at the nature of the dependency, the underlying code base, and the long-term prospect for development. And hence it’s not the first time that we deal with a useful concept—and not the last time that it’s not enough to make good decisions. Which is not to imply Adam said anything else.

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (Please be critical, interpret charitably, and give feedback.)