HTML, CSS, and Dependency Direction
Post from February 14, 2018 (↻ October 1, 2022), filed under Web Development.
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 though, 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.”
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.
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 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 need to look 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|
|2000’s||n||1 to n|
|Multi-domain, multi-client sites||n||n|
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 really 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 alerting other teams.
We may well talk dependency direction but we wouldn’t be very 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 my very 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 long-term data to tell what difference HTML ← CSS (HTML depending on CSS) and CSS ← HTML (CSS depending on HTML) make.
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—currently manager for Developer Experience at LivePerson—and author. I’ve worked as a technical lead for Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly. I love trying things, sometimes including philosophy, art, and adventure. 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 this is interesting 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 The Web Development Glossary (2020). With explanations and definitions for literally thousands of terms from Web Development and related fields, building on Wikipedia as well as the MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.