The Two Extremes of Writing CSS, and What We Can Learn From Them

Published on January 2, 2018 (↻ June 19, 2024), filed under (RSS feed for all categories).

Extremes can be useful. In practice they help get the maximum out of a given approach, and in theory they can show what we’re headed to.

For the purposes of this article, there are two extremes in writing CSS, in connection with the underlying HTML. One is to have a presentational ID or class for every styling purpose. Two is not to use any IDs and classes at all.

One is much like Tachyons and Atomic CSS. Two is like 2000’s idealistic engineering.

One looks like (using a Tachyons banner):

<!DOCTYPE html>
<article class="mw7 center ph3 ph5-ns tc br2 pv5 bg-washed-green dark-green mb5">
  <h1 class="fw6 f3 f2-ns lh-title mt0 mb3">This is a tagline. For x.</h1>
  <h2 class="fw2 f4 lh-copy mt0 mb3">This will change things. And we want you to be involved. This text needs to be longer for testing sake.</h2>
  <p class="fw1 f5 mt0 mb3">Sign up for beta access or learn more about x.
  <div><a class="f6 br-pill bg-dark-green no-underline washed-green ba b--dark-green grow pv2 ph3 dib mr3" href=#>Sign Up</a> <a class="f6 br-pill dark-green no-underline ba grow pv2 ph3 dib" href=#>Learn More</a></div>

Two looks like:

<!DOCTYPE html>
  <h1>This is a tagline. For x.</h1>
  <h2>This will change things. And we want you to be involved. This text needs to be longer for testing sake.</h2>
  <p>Sign up for beta access or learn more about x.
  <div><a href=#>Sign Up</a> <a href=#>Learn More</a></div>

Two means complexity and maintenance of CSS (there just isn’t much in the HTML). One means complexity in HTML and maintenance of CSS.

One, to go by order, means putting presentation first and seeing what one gets. Two means putting structure first and being agnostic of what one gets.

One is modular. Two is holistic.

One is specific. Two is abstract.

One is easy on teams. Two is instructive for teams.

One is is easier for understanding. Two is better for quality.

One, again, is presentational markup. Two, also to remind us, is bare-bones functional markup.

I will not conclude with a table for comparison or more assessing (judging?) thoughts. I will instead say, we can make and we do make these choices. Most of us cope with a compromise: There are plenty of developers who favor neither the presentational approach nor the bare-bones one.

Let’s be aware, then, that the situation is not symmetrical. On the low complexity end, the bare-bones approach seems to work much better than the presentational one. On the high complexity end, particular with a modular, dynamic, almost app-like vision of website development, as well as distributed teams, the presentational approach seems to be more manageable.

From my point of view, what makes web development so interesting is that it depends on a number of variables and probabilities. In earlier years I’d have been inclined to strictly advise for one approach. These days I find more use in identifying the poles the field is located between. These poles, or extremes, we can then use for navigation—and we can use these two poles, the one of presentation-stuffed HTML and the one of complexity-laden CSS, to navigate, too.

Was this useful or interesting? Share (toot) this post, or maybe treat me to a coffee. Thanks!

About Me

Jens Oliver Meiert, on September 30, 2021.

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 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 (and engineering management), but also in other areas like philosophy. Here on I share some of my views and experiences.

If you want to do me a favor, interpret charitably (I speak three languages, and they can collide), yet be critical and give feedback for me to learn and improve. Thank you!