Jens Oliver Meiert

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

Post from January 2, 2018 (↻ October 5, 2018), filed under .

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>
<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.

About the Author

Jens Oliver Meiert, photo of September 22, 2018.

Jens Oliver Meiert is an author and developer (O’Reilly, W3C, ex-Google). He plays with philosophy, art, and adventure. Here on meiert.com he shares and generalizes and exaggerates some of his thoughts and experiences.

There’s more Jens in the archives and at Goodreads. If you have any questions or concerns (or recommendations) about what he writes, leave a comment or a message.

Comments (Closed)

  1. On January 3, 2018, 13:11 CET, Tony Ruscoe said:

    I’ve been thinking about something similar for a while, because I’ve heard too many developers choose their preferred methodology (regardless of the project or context) rather than trying to understand the benefits of each methodology and when it might be more appropriate to use one over another. We should use the right tool for the job, as they say.

    One means complexity in HTML and maintenance of CSS.

    I think one idea behind frameworks like Tachyons, Atomic CSS, or Basscss is that the CSS needs maintaining less often because the rules should be pretty exhaustive and primitive-like. Any visual changes would therefore be maintained in the HTML, which would probably benefit from being implemented as atomic templates.

    Thanks for writing this!

  2. On January 4, 2018, 10:00 CET, jmanuels said:

    Isn’t the other extreme pole to clean markup using inline styles, e.g. style=”my totally individualistic and concrete style”, rather than “atomic css”?

  3. On January 4, 2018, 11:02 CET, Jens Oliver Meiert said:

    Thanks Tony! As for CSS maintenance around Tachyons and Atomic CSS, if I get your point right, the promise seems indeed that there isn’t that much to do (everything is in the HTML); yet how much CSS is being piled up, and how is it dealt with in the long run, whether in iterations or relaunches? I’m not entirely clear about the answers apart from the suspicion that there’s not as little work involved as originally thought. Maybe peers with long-term exposure to this can comment 😊

    J., in terms of maintenance we can probably regard these as equivalent for style="margin: 10px" is no worse really than class=m10 or such. I haven’t included this approach for I’d hope that this problem, we have addressed by now (or limited to the few use cases in which @style is defensible).

Read More

Have a look at the most popular posts, possibly including:

Say hello on Twitter or LinkedIn.

Looking for a way to comment? Comments have been disabled, unfortunately.

Found a mistake? Email me, jens@meiert.com.

You are here: HomeArchive2018 → The Two Extremes of Writing CSS, and What We Can Learn from Them

Last update: October 5, 2018

Awareness, honesty, responsibility.