HTML, CSS, and Dependency Direction
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:
“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-biothat 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.
“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.
(That’s not to say dependency direction was not a great way to think about the link between HTML and CSS.)
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
|1 to n
|Multi-domain, multi-client sites
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
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.
I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for companies like Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly and Frontend Dogma. I love trying things, not only in web development, but also in other areas like philosophy. Here on meiert.com I share some of my views and experiences.
If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!
Maybe of interest to you, too:
- Next: User-Centered Web Development
- Previous: How Declaration Repetition Developed over Time, a Statistically Insignificant Sample
- More under Web Development, or from 2018
- Most popular posts
Looking for a way to comment? Comments have been disabled, unfortunately.
Get a good look at web development? Try WebGlossary.info—and The Web Development Glossary 3K (2023). With explanations and definitions for thousands of terms of web development, web design, and related fields, building on Wikipedia as well as MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.