The Two Extremes of Writing CSS, and What We Can Learn from Them
Post from January 2, 2018 (↻ June 1, 2021), filed under Web Development.
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 looks like (using a Tachyons banner):
<!DOCTYPE html> <title>Example</title> <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> </article>
Two looks like:
<!DOCTYPE html> <title>Example</title> <article> <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> </article>
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.
I’m Jens Oliver Meiert, and I’m an engineering manager and author. I’ve worked as a technical lead for Google, I’m close to the W3C and the WHATWG, and I write and review books for O’Reilly. Other than that, 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 questions or suggestions about what I write, please leave a comment (if available) or a message.
Have a look at the most popular posts, possibly including:
Looking for a way to comment? Comments have been disabled, unfortunately.
Perhaps my most comprehensive book: 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.